[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y4TgDZPTXnnoTitB@google.com>
Date: Mon, 28 Nov 2022 16:21:33 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: Marc Orr <marcorr@...gle.com>
Cc: Chao Peng <chao.p.peng@...ux.intel.com>,
Vishal Annapurve <vannapurve@...gle.com>, x86@...nel.org,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org, pbonzini@...hat.com,
vkuznets@...hat.com, wanpengli@...cent.com, jmattson@...gle.com,
joro@...tes.org, tglx@...utronix.de, mingo@...hat.com,
bp@...en8.de, dave.hansen@...ux.intel.com, hpa@...or.com,
shuah@...nel.org, yang.zhong@...el.com, ricarkol@...gle.com,
aaronlewis@...gle.com, wei.w.wang@...el.com,
kirill.shutemov@...ux.intel.com, corbet@....net, hughd@...gle.com,
jlayton@...nel.org, bfields@...ldses.org,
akpm@...ux-foundation.org, yu.c.zhang@...ux.intel.com,
jun.nakajima@...el.com, dave.hansen@...el.com,
michael.roth@....com, qperret@...gle.com, steven.price@....com,
ak@...ux.intel.com, david@...hat.com, luto@...nel.org,
vbabka@...e.cz, erdemaktas@...gle.com, pgonda@...gle.com,
nikunj@....com, diviness@...gle.com, maz@...nel.org,
dmatlack@...gle.com, axelrasmussen@...gle.com,
maciej.szmigiero@...cle.com, mizhang@...gle.com,
bgardon@...gle.com, ackerleytng@...gle.com
Subject: Re: [V1 PATCH 1/6] KVM: x86: Add support for testing private memory
On Wed, Nov 23, 2022, Marc Orr wrote:
> On Tue, Nov 22, 2022 at 12:06 PM Sean Christopherson <seanjc@...gle.com> wrote:
> > > > @@ -221,6 +220,9 @@ struct kvm_page_fault {
> > > > /* The memslot containing gfn. May be NULL. */
> > > > struct kvm_memory_slot *slot;
> > > >
> > > > + /* Derived from encryption bits of the faulting GPA for CVMs. */
> > > > + bool is_private;
> > >
> > > Either we can wrap it with the CONFIG_HAVE_KVM_PRIVATE_MEM_TESTING or if
> > > it looks ugly I can remove the "const" in my code.
> >
> > Hmm, I think we can keep the const. Similar to the bug in kvm_faultin_pfn()[*],
> > the kvm_slot_can_be_private() is bogus. A fault should be considered private if
> > it's marked as private, whether or not userspace has configured the slot to be
> > private is irrelevant. I.e. the xarray is the single source of truth, memslots
> > are just plumbing.
>
> If we incorporate Sean's suggestion and use xarray as the single
> source of truth, then can we get rid of the
> HAVE_KVM_PRIVATE_MEM_TESTING config?
No, we still want the opt-in config.
> Specifically, the self test can call the KVM_MEMORY_ENCRYPT_REG_REGION
> ioctl which will set the bits for the private FD within KVM's xarray.
Yes, but that should be disallowed for regular VMs without HAVE_KVM_PRIVATE_MEM_TESTING=y.
> (Maybe this was part of the point that Sean was making; but his
> feedback seemed focused on the discussion about keeping `is_private`
> const, whereas I've been staring at this trying to figure out if we
> can run the UPM selftests on a non-TDX/SNP VM WITHOUT a special
> test-only config. And Sean's idea seems to eliminate the need for the
> awkward CONFIG.)
"need" was always relative. It's obviously possible to enable any code without a
Kconfig, the question is whether or not it's a good idea to do so. In this case,
the answer is "no", because allowing private memory opens up a number a of code
paths and thus potential bugs. And we need something for kvm_arch_has_private_mem()
because returning "true" unconditionally is not correct for regular VMs.
Powered by blists - more mailing lists