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

[Ackerley Tng]

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.