On 19.04.23 17:17, Sean Christopherson wrote:
On Wed, Apr 19, 2023, David Hildenbrand wrote:
On 19.04.23 02:47, Sean Christopherson wrote:
On Tue, Apr 18, 2023, David Hildenbrand wrote:
"memfd_vm" / "vm_mem" would be sooo (feel free to add some more o's here)
much easier to get. It's a special fd to be used to back VM memory. Depending
on the VM type (encrypted/protected/whatever), restrictions might apply (not
able to mmap, not able to read/write ...). For example, there really is no
need to disallow mmap/read/write when using that memory to back a simple VM
where all we want to do is avoid user-space page tables.
In seriousness, I do agree with Jason's very explicit objection[2] against naming
a non-KVM uAPI "guest", or any variation thereof.
While I agree, it's all better than the naming we use right now ...
Let me throw "tee_mem" / "memfd_tee" into the picture. That could eventually
catch what we want to have.
Or "coco_mem" / "memfd_coco".
Of course, both expect that people know the terminology (just like what "vm"
stands for), but it's IMHO significantly better than
restricted/guarded/opaque/whatsoever.
Again, expresses what it's used for, not why it behaves in weird ways.
I don't want to explicitly tie this to trusted execution or confidential compute,
as there is value in backing "normal" guests with memory that cannot be accessed
by the host userspace without jumping through a few extra hoops, e.g. to add a
layer of protection against data corruption due to host userspace bugs.
Nothing speaks against using tee_mem for the same purpose I guess. I
like the sound of it after all. :)
--
Thanks,
David / dhildenb
