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).
How about "opaque"?
I think opaque captures the idea of enforced information hiding from the
user(space), and that the contents can only be manipulated via internal
(kernel) functions.
