[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <diqz5y9t86qi.fsf@ackerleytng-cloudtop.c.googlers.com>
Date: Tue, 18 Apr 2023 17:01:25 +0000
From: Ackerley Tng <ackerleytng@...gle.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: david@...hat.com, chao.p.peng@...ux.intel.com, pbonzini@...hat.com,
vkuznets@...hat.com, jmattson@...gle.com, joro@...tes.org,
mail@...iej.szmigiero.name, vbabka@...e.cz, vannapurve@...gle.com,
yu.c.zhang@...ux.intel.com, kirill.shutemov@...ux.intel.com,
dhildenb@...hat.com, qperret@...gle.com, tabba@...gle.com,
michael.roth@....com, wei.w.wang@...el.com, rppt@...nel.org,
liam.merwick@...cle.com, isaku.yamahata@...il.com,
jarkko@...nel.org, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: Rename restrictedmem => guardedmem? (was: Re: [PATCH v10 0/9]
KVM: mm: fd-based approach for supporting KVM)
Sean Christopherson <seanjc@...gle.com> 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.
Powered by blists - more mailing lists