kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Isaku Yamahata <isaku.yamahata@gmail.com>
To: Michael Roth <michael.roth@amd.com>
Cc: Isaku Yamahata <isaku.yamahata@gmail.com>,
	kvm@vger.kernel.org, linux-coco@lists.linux.dev,
	linux-mm@kvack.org, linux-crypto@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, tglx@linutronix.de,
	mingo@redhat.com, jroedel@suse.de, thomas.lendacky@amd.com,
	hpa@zytor.com, ardb@kernel.org, pbonzini@redhat.com,
	seanjc@google.com, vkuznets@redhat.com, jmattson@google.com,
	luto@kernel.org, dave.hansen@linux.intel.com, slp@redhat.com,
	pgonda@google.com, peterz@infradead.org,
	srinivas.pandruvada@linux.intel.com, rientjes@google.com,
	dovmurik@linux.ibm.com, tobin@ibm.com, bp@alien8.de,
	vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com,
	tony.luck@intel.com, marcorr@google.com,
	sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com,
	dgilbert@redhat.com, jarkko@kernel.org, ashish.kalra@amd.com,
	nikunj.dadhania@amd.com, liam.merwick@oracle.com,
	zhi.a.wang@intel.com
Subject: Re: [PATCH RFC v9 04/51] KVM: x86: Determine shared/private faults using a configurable mask
Date: Tue, 20 Jun 2023 14:18:45 -0700	[thread overview]
Message-ID: <20230620211845.GV2244082@ls.amr.corp.intel.com> (raw)
In-Reply-To: <20230620202841.7qizls3u3kcck45g@amd.com>

On Tue, Jun 20, 2023 at 03:28:41PM -0500,
Michael Roth <michael.roth@amd.com> wrote:

> On Wed, Jun 14, 2023 at 09:47:09AM -0700, Isaku Yamahata wrote:
> > On Sun, Jun 11, 2023 at 11:25:12PM -0500,
> > Michael Roth <michael.roth@amd.com> wrote:
> > 
> > > This will be used to determine whether or not an #NPF should be serviced
> > > using a normal page vs. a guarded/gmem one.
> > > 
> > > Signed-off-by: Michael Roth <michael.roth@amd.com>
> > > ---
> > >  arch/x86/include/asm/kvm_host.h |  7 +++++++
> > >  arch/x86/kvm/mmu/mmu_internal.h | 35 ++++++++++++++++++++++++++++++++-
> > >  2 files changed, 41 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> > > index b3bd24f2a390..c26f76641121 100644
> > > --- a/arch/x86/include/asm/kvm_host.h
> > > +++ b/arch/x86/include/asm/kvm_host.h
> > > @@ -1445,6 +1445,13 @@ struct kvm_arch {
> > >  	 */
> > >  #define SPLIT_DESC_CACHE_MIN_NR_OBJECTS (SPTE_ENT_PER_PAGE + 1)
> > >  	struct kvm_mmu_memory_cache split_desc_cache;
> > > +
> > > +	/*
> > > +	 * When set, used to determine whether a fault should be treated as
> > > +	 * private in the context of protected VMs which use a separate gmem
> > > +	 * pool to back private guest pages.
> > > +	 */
> > > +	u64 mmu_private_fault_mask;
> > >  };
> > >  
> > >  struct kvm_vm_stat {
> > > diff --git a/arch/x86/kvm/mmu/mmu_internal.h b/arch/x86/kvm/mmu/mmu_internal.h
> > > index 780b91e1da9f..9b9e75aa43f4 100644
> > > --- a/arch/x86/kvm/mmu/mmu_internal.h
> > > +++ b/arch/x86/kvm/mmu/mmu_internal.h
> > > @@ -252,6 +252,39 @@ struct kvm_page_fault {
> > >  
> > >  int kvm_tdp_page_fault(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault);
> > >  
> > > +static bool kvm_mmu_fault_is_private(struct kvm *kvm, gpa_t gpa, u64 err)
> > > +{
> > > +	struct kvm_memory_slot *slot;
> > > +	bool private_fault = false;
> > > +	gfn_t gfn = gpa_to_gfn(gpa);
> > > +
> > > +	slot = gfn_to_memslot(kvm, gfn);
> > > +	if (!slot) {
> > > +		pr_debug("%s: no slot, GFN: 0x%llx\n", __func__, gfn);
> > > +		goto out;
> > > +	}
> > > +
> > > +	if (!kvm_slot_can_be_private(slot)) {
> > > +		pr_debug("%s: slot is not private, GFN: 0x%llx\n", __func__, gfn);
> > > +		goto out;
> > > +	}
> > > +
> > > +	if (kvm->arch.mmu_private_fault_mask) {
> > > +		private_fault = !!(err & kvm->arch.mmu_private_fault_mask);
> > > +		goto out;
> > > +	}
> > 
> > What's the convention of err? Can we abstract it by introducing a new bit
> > PFERR_PRIVATE_MASK? The caller sets it based on arch specific value.
> > the logic will be
> >         .is_private = err & PFERR_PRIVATE_MASK;
> 
> I'm not sure I understand the question. 'err' is just the page fault flags,
> and arch.mmu_private_fault_mask is something that can be set on a
> per-platform basis when running in a mode where shared/private access
> is recorded in the page fault flags during a #NPF.
> 
> I'm not sure how we'd keep the handling cross-platform by moving to a macro,
> since TDX uses a different bit, and we'd want to be able to build a
> SNP+TDX kernel that could run on either type of hardware.
> 
> Are you suggesting to reverse that and have err be set in a platform-specific
> way and then use a common PFERR_PRIVATE_MASK that's software-defined and
> consistent across platforms? That could work, but existing handling seems
> to use page fault flags as-is, keeping the hardware-set values, rather than
> modifying them to pass additional metadata, so it seems like it might
> make things more confusing to make an exception to that here. Or are
> there other cases where it's done that way?

I meant the latter, making PFERR_PRIVATE_MASK common software-defined.

I think the SVM fault handler can use hardware value directly by carefully
defining those PFERR values.

TDX doesn't have architectural bit in error code to indicate the private fault.
It's coded in faulted address as shared bit. GPA bit 51 or 47.
PFERR_{USER, WRITE, FETCH, PRESENT} are already software-defined value for VMX
(and TDX).  The fault handler for VMX, handle_ept_violation(), converts
encoding.  For TDX, PFERR_PRIVATE_MASK is just one more software defined bit.

I'm fine with either way, variable or macro. Which do you prefer?

- Define variable mmu_private_fault_mask (global or per struct kvm)
  The module initialization code, hardware_setup(), sets mmu_private_fault_mask.
- Define the software defined value, PFERR_PRIVATE_MASK.
  The caller of kvm_mmu_page_fault() parses the hardware value and construct
  software defined error_code.
- any other?
  

> > > +
> > > +	/*
> > > +	 * Handling below is for UPM self-tests and guests that treat userspace
> > > +	 * as the authority on whether a fault should be private or not.
> > > +	 */
> > > +	private_fault = kvm_mem_is_private(kvm, gpa >> PAGE_SHIFT);
> > 
> > This code path is sad. One extra slot lookup and xarray look up.
> > Without mmu lock, the result can change by other vcpu.
> > Let's find a better way.
> 
> The intention was to rely on fault->mmu_seq to determine if a
> KVM_SET_MEMORY_ATTRIBUTES update came in after .private_fault was set so
> that fault handling could be retried, but that doesn't happen until
> kvm_faultin_pfn() which is *after* this is logged. So yes, I think there
> is a race here, and the approach you took in your Misc. series of
> keeping the kvm_mem_is_private() check inside kvm_faultin_pfn() is more
> efficient/correct.
> 
> If we can figure out a way to handle checking the fault flags in a way
> that works for both TDX/SNP (and KVM self-test use-case) we can
> consolidate around that.

I can think of the following ways. I think the second option is better because
we don't need exit bit for error code.

- Introduce software defined error code
- Add a flags to struct kvm_arch for self-test use-case VM_TYPE_PROTECTED_VM.
  Set it to true for VM_TYPE_PROTECTED_VM case.
- any other?

Thanks,
-- 
Isaku Yamahata <isaku.yamahata@gmail.com>

  reply	other threads:[~2023-06-20 21:18 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-12  4:25 [PATCH RFC v9 00/51] Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 01/51] KVM: x86: Add gmem hook for initializing private memory Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 02/51] KVM: x86: Add gmem hook for invalidating " Michael Roth
2023-06-12 10:49   ` Borislav Petkov
2023-06-19 13:39     ` Borislav Petkov
2023-06-12  4:25 ` [PATCH RFC v9 03/51] KVM: x86: Use full 64-bit error code for kvm_mmu_do_page_fault Michael Roth
2023-06-14 14:24   ` Isaku Yamahata
2023-06-12  4:25 ` [PATCH RFC v9 04/51] KVM: x86: Determine shared/private faults using a configurable mask Michael Roth
2023-06-14 16:47   ` Isaku Yamahata
2023-06-20 20:28     ` Michael Roth
2023-06-20 21:18       ` Isaku Yamahata [this message]
2023-06-21 23:00         ` Michael Roth
2023-06-22  8:01           ` Isaku Yamahata
2023-06-22  9:55           ` Huang, Kai
2023-06-22 15:32             ` Michael Roth
2023-06-22 22:31               ` Huang, Kai
2023-06-22 23:39                 ` Isaku Yamahata
2023-06-22 23:52                   ` Huang, Kai
2023-06-23 14:43                     ` Isaku Yamahata
2023-06-19 16:27   ` Borislav Petkov
2023-06-20 20:36     ` Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 05/51] x86/coco: move CONFIG_HAS_CC_PLATFORM check down into coco/Makefile Michael Roth
2023-06-12  7:07   ` Kirill A . Shutemov
2023-06-20 12:09   ` Borislav Petkov
2023-06-20 20:43     ` Michael Roth
2023-06-21  8:54       ` Borislav Petkov
2023-06-29 21:02         ` Michael Roth
2023-07-10  3:05   ` Sathyanarayanan Kuppuswamy
2023-07-10 13:11     ` Tom Lendacky
2023-06-12  4:25 ` [PATCH RFC v9 06/51] x86/cpufeatures: Add SEV-SNP CPU feature Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 07/51] x86/sev: Add the host SEV-SNP initialization support Michael Roth
2023-06-12 15:34   ` Dave Hansen
2023-06-21  9:15     ` Borislav Petkov
2023-06-21 14:31       ` Dave Hansen
2023-06-21 15:59         ` Borislav Petkov
2023-06-21  9:42   ` Borislav Petkov
2023-06-21 14:36     ` Tom Lendacky
2023-06-21 19:15     ` Kalra, Ashish
2023-08-09 13:03   ` Jeremi Piotrowski
2023-06-12  4:25 ` [PATCH RFC v9 08/51] x86/speculation: Do not enable Automatic IBRS if SEV SNP is enabled Michael Roth
2023-06-12 15:39   ` Dave Hansen
2023-07-18 22:34     ` Kim Phillips
2023-07-18 23:17       ` Dave Hansen
2023-07-20 19:11         ` Kim Phillips
2023-07-20 22:24           ` Dave Hansen
2023-07-21 16:56             ` Kim Phillips
2023-06-12  4:25 ` [PATCH RFC v9 09/51] x86/sev: Add RMP entry lookup helpers Michael Roth
2023-06-12 16:08   ` Dave Hansen
2023-06-30 21:57     ` Michael Roth
2023-06-30 22:29       ` Dave Hansen
2023-06-12  4:25 ` [PATCH RFC v9 10/51] x86/fault: Add helper for dumping RMP entries Michael Roth
2023-06-12 16:12   ` Dave Hansen
2023-06-12  4:25 ` [PATCH RFC v9 11/51] x86/traps: Define RMP violation #PF error code Michael Roth
2023-06-12 16:26   ` Dave Hansen
2023-06-12  4:25 ` [PATCH RFC v9 12/51] x86/fault: Report RMP page faults for kernel addresses Michael Roth
2023-06-12 16:30   ` Dave Hansen
2023-06-12  4:25 ` [PATCH RFC v9 13/51] x86/fault: Handle RMP page faults for user addresses Michael Roth
2023-06-12 16:40   ` Dave Hansen
2023-06-12  4:25 ` [PATCH RFC v9 14/51] x86/sev: Add helper functions for RMPUPDATE and PSMASH instruction Michael Roth
2023-06-12 17:00   ` Dave Hansen
2023-06-12  4:25 ` [PATCH RFC v9 15/51] x86/sev: Invalidate pages from the direct map when adding them to the RMP table Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 16/51] crypto: ccp: Define the SEV-SNP commands Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 17/51] crypto: ccp: Add support to initialize the AMD-SP for SEV-SNP Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 18/51] crypto: ccp: Provide API to issue SEV and SNP commands Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 19/51] x86/sev: Introduce snp leaked pages list Michael Roth
2023-08-09 12:46   ` Jeremi Piotrowski
2023-06-12  4:25 ` [PATCH RFC v9 20/51] crypto: ccp: Handle the legacy TMR allocation when SNP is enabled Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 21/51] crypto: ccp: Handle the legacy SEV command " Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 22/51] crypto: ccp: Add the SNP_PLATFORM_STATUS command Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 23/51] KVM: SEV: Select CONFIG_KVM_PROTECTED_VM when CONFIG_KVM_AMD_SEV=y Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 24/51] KVM: SVM: Add support to handle AP reset MSR protocol Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 25/51] KVM: SVM: Add GHCB handling for Hypervisor Feature Support requests Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 26/51] KVM: SVM: Make AVIC backing, VMSA and VMCB memory allocation SNP safe Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 27/51] KVM: SVM: Add initial SEV-SNP support Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 28/51] KVM: SVM: Add KVM_SNP_INIT command Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 29/51] KVM: SVM: Add KVM_SEV_SNP_LAUNCH_START command Michael Roth
2023-06-12 17:08   ` Peter Gonda
2023-06-12  4:25 ` [PATCH RFC v9 30/51] KVM: Add HVA range operator Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 31/51] KVM: Split out memory attribute xarray updates to helper function Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 32/51] KVM: SVM: Add KVM_SEV_SNP_LAUNCH_UPDATE command Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 33/51] KVM: SVM: Add KVM_SEV_SNP_LAUNCH_FINISH command Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 34/51] KVM: SVM: Add support to handle GHCB GPA register VMGEXIT Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 35/51] KVM: SVM: Add KVM_EXIT_VMGEXIT Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 36/51] KVM: SVM: Add support to handle MSR based Page State Change VMGEXIT Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 37/51] KVM: SVM: Add support to handle " Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 38/51] KVM: x86: Export the kvm_zap_gfn_range() for the SNP use Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 39/51] KVM: x86: Define RMP page fault error bits for #NPF Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 40/51] KVM: SVM: Add support to handle RMP nested page faults Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 41/51] KVM: SVM: Use a VMSA physical address variable for populating VMCB Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 42/51] KVM: SVM: Support SEV-SNP AP Creation NAE event Michael Roth
2023-08-15 16:00   ` Peter Gonda
2023-06-12  4:25 ` [PATCH RFC v9 43/51] KVM: SEV: Configure MMU to check for private fault flags Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 44/51] KVM: SEV: Implement gmem hook for initializing private pages Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 45/51] KVM: SEV: Implement gmem hook for invalidating " Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 46/51] KVM: SVM: Add module parameter to enable the SEV-SNP Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 47/51] iommu/amd: Add IOMMU_SNP_SHUTDOWN support Michael Roth
2023-09-07 10:31   ` Suthikulpanit, Suravee
2023-06-12  4:25 ` [PATCH RFC v9 48/51] crypto: ccp: Add the SNP_{SET,GET}_EXT_CONFIG command Michael Roth
2023-06-13  6:24   ` Alexey Kardashevskiy
2023-06-12  4:25 ` [PATCH RFC v9 49/51] x86/sev: Add KVM commands for per-instance certs Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 50/51] KVM: SVM: Provide support for SNP_GUEST_REQUEST NAE event Michael Roth
2023-06-12  4:25 ` [PATCH RFC v9 51/51] crypto: ccp: Add debug support for decrypting pages Michael Roth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230620211845.GV2244082@ls.amr.corp.intel.com \
    --to=isaku.yamahata@gmail.com \
    --cc=ak@linux.intel.com \
    --cc=alpergun@google.com \
    --cc=ardb@kernel.org \
    --cc=ashish.kalra@amd.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dgilbert@redhat.com \
    --cc=dovmurik@linux.ibm.com \
    --cc=hpa@zytor.com \
    --cc=jarkko@kernel.org \
    --cc=jmattson@google.com \
    --cc=jroedel@suse.de \
    --cc=kirill@shutemov.name \
    --cc=kvm@vger.kernel.org \
    --cc=liam.merwick@oracle.com \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=marcorr@google.com \
    --cc=michael.roth@amd.com \
    --cc=mingo@redhat.com \
    --cc=nikunj.dadhania@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pgonda@google.com \
    --cc=rientjes@google.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=seanjc@google.com \
    --cc=slp@redhat.com \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=tobin@ibm.com \
    --cc=tony.luck@intel.com \
    --cc=vbabka@suse.cz \
    --cc=vkuznets@redhat.com \
    --cc=x86@kernel.org \
    --cc=zhi.a.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).