Sean Christopherson <seanjc@xxxxxxxxxx> writes:
On Mon, Apr 17, 2023, David Hildenbrand wrote:
On 17.04.23 17:40, Sean Christopherson wrote:
> 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 ...
I'm definitely open to other suggestions, but I suspect it's going to be
difficult
to be more precise than something like "guarded".
E.g. we discussed "unmappable" at one point, but the memory can still be
mapped,
just not via mmap(). And it's not just about mappings, e.g. read() and
its many
variants are all disallowed too, despite the kernel direct map still
being live
(modulo SNP requirements).
I'm for renaming the concept because restrictedmem is quite a
mouthful. :)
How about "concealedmem" or "obscuredmem" to highlight the idea of this
memory being hidden/unreadable/unmappable from userspace?
Guarded is better than restricted but doesn't really highlight how/in
what way it is being guarded.
