Re: Rename restrictedmem => guardedmem? (was: Re: [PATCH v10 0/9] KVM: mm: fd-based approach for supporting KVM)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06.05.23 09:44, Vlastimil Babka wrote:
On 5/5/23 22:00, David Hildenbrand wrote:
On 23.04.23 15:28, Jarkko Sakkinen wrote:
On Mon Apr 17, 2023 at 6:48 PM EEST, David Hildenbrand wrote:
On 17.04.23 17:40, Sean Christopherson wrote:
What do y'all think about renaming "restrictedmem" to "guardedmem"?

Yeay, let's add more confusion :D

If we're at renaming, I'd appreciate if we could find a terminology that
does look/sound less horrible.


I want to start referring to the code/patches by its syscall/implementation name
instead of "UPM", as "UPM" is (a) very KVM centric, (b) refers to the broader effort
and not just the non-KVM code, and (c) will likely be confusing for future reviewers
since there's nothing in the code that mentions "UPM" in any way.

But typing out restrictedmem is quite tedious, and git grep shows that "rmem" is
already used to refer to "reserved memory".

Renaming the syscall to "guardedmem"...

restrictedmem, guardedmem, ... all fairly "suboptimal" if you'd ask me ...

In the world of TEE's and confidential computing it is fairly common to
call memory areas enclaves, even outside SGX context. So in that sense
enclave memory would be the most correct terminology.

I was also thinking along the lines of isolated_mem or imem ...
essentially, isolated from (unprivileged) user space.

... if we still want to have a common syscall for it.

I'm fan of the ioctl, if it has a chance of working out.
Yes, me too.

--
Thanks,

David / dhildenb




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux