All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Kai Huang <kai.huang@intel.com>
Cc: "isaku.yamahata@gmail.com" <isaku.yamahata@gmail.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	 Rick P Edgecombe <rick.p.edgecombe@intel.com>,
	"michael.roth@amd.com" <michael.roth@amd.com>,
	 "pankaj.gupta@amd.com" <pankaj.gupta@amd.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	 "tobin@ibm.com" <tobin@ibm.com>,
	"liam.merwick@oracle.com" <liam.merwick@oracle.com>,
	 "alpergun@google.com" <alpergun@google.com>,
	Tony Luck <tony.luck@intel.com>,
	 "jmattson@google.com" <jmattson@google.com>,
	"luto@kernel.org" <luto@kernel.org>,
	 "ak@linux.intel.com" <ak@linux.intel.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	 "pgonda@google.com" <pgonda@google.com>,
	 "srinivas.pandruvada@linux.intel.com"
	<srinivas.pandruvada@linux.intel.com>,
	"slp@redhat.com" <slp@redhat.com>,
	 "rientjes@google.com" <rientjes@google.com>,
	"peterz@infradead.org" <peterz@infradead.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	 "dovmurik@linux.ibm.com" <dovmurik@linux.ibm.com>,
	 "thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
	"x86@kernel.org" <x86@kernel.org>, "bp@alien8.de" <bp@alien8.de>,
	 "vkuznets@redhat.com" <vkuznets@redhat.com>,
	"vbabka@suse.cz" <vbabka@suse.cz>,
	 "ashish.kalra@amd.com" <ashish.kalra@amd.com>,
	 "linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
	 "nikunj.dadhania@amd.com" <nikunj.dadhania@amd.com>,
	Jorg Rodel <jroedel@suse.de>,
	 "mingo@redhat.com" <mingo@redhat.com>,
	 "sathyanarayanan.kuppuswamy@linux.intel.com"
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	 "hpa@zytor.com" <hpa@zytor.com>,
	"kirill@shutemov.name" <kirill@shutemov.name>,
	 "jarkko@kernel.org" <jarkko@kernel.org>,
	"ardb@kernel.org" <ardb@kernel.org>,
	 "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	 "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>
Subject: Re: [PATCH v15 13/20] KVM: SEV: Implement gmem hook for initializing private pages
Date: Mon, 20 May 2024 17:30:15 -0700	[thread overview]
Message-ID: <ZkvrFw1QMtImegQD@google.com> (raw)
In-Reply-To: <1ce87335-2ea7-41c4-8442-36210656cdca@intel.com>

On Tue, May 21, 2024, Kai Huang wrote:
> On 21/05/2024 11:15 am, Sean Christopherson wrote:
> > On Tue, May 21, 2024, Kai Huang wrote:
> > > On 21/05/2024 5:35 am, Sean Christopherson wrote:
> > > > On Mon, May 20, 2024, Kai Huang wrote:
> > > > > I am wondering whether this can be done in the KVM page fault handler?
> > > > 
> > > > No, because the state of a pfn in the RMP is tied to the guest_memfd inode,
> > > > not to the file descriptor, i.e. not to an individual VM.
> > > 
> > > It's strange that as state of a PFN of SNP doesn't bind to individual VM, at
> > > least for the private pages.  The command rpm_make_private() indeed reflects
> > > the mapping between PFN <-> <GFN, SSID>.
> > 
> > s/SSID/ASID
> > 
> > KVM allows a single ASID to be bound to multiple "struct kvm" instances, e.g.
> > for intra-host migration.  If/when trusted I/O is a thing, presumably KVM will
> > also need to share the ASID with other entities, e.g. IOMMUFD.
> 
> But is this the case for SNP?  I thought due to the nature of private pages,
> they cannot be shared between VMs?  So to me this RMP entry mapping for PFN
> <-> GFN for private page should just be per-VM.

Sorry to redirect, but please read this mail (and probably surrounding mails).
It hopefully explains most of the question you have.

https://lore.kernel.org/all/ZLGiEfJZTyl7M8mS@google.com

> > Regardless of whether or not guest_memfd supports page migration, KVM needs to
> > track the state of the physical page in guest_memfd, e.g. if it's been assigned
> > to the ASID versus if it's still in a shared state.
> 
> I am not certain this can impact whether we want to do RMP commands via
> guest_memfd() hooks or TDP MMU hooks?
>
> > > If we truly want to zap private mappings for SNP, IIUC it can be done by
> > > distinguishing whether a VM needs to use a separate private table, which is
> > > TDX-only.
> > 
> > I wouldn't say we "want" to zap private mappings for SNP, rather that it's a lot
> > less work to keep KVM's existing behavior (literally do nothing) than it is to
> > rework the MMU and whatnot to not zap SPTEs.
> 
> My thinking too.
> 
> > And there's no big motivation to avoid zapping because SNP VMs are unlikely
> > to delete memslots.
> 
> I think we should also consider MMU notifier?

No, private mappings have no host userspace mappings, i.e. are completely exempt
from MMU notifier events.  guest_memfd() can still invalidate mappings, but that
only occurs if userspace punches a hole, which is destructive.

> > If it turns out that it's easy to preserve SNP mappings after TDX lands, then we
> > can certainly go that route, but AFAIK there's no reason to force the issue.
> 
> No I am certainly not saying we should do SNP after TDX.  Sorry I didn't
> closely monitor the status of this SNP patchset.
> 
> My intention is just wanting to make the TDP MMU common code change more
> useful (since we need that for TDX anyway), i.e., not effectively just for
> TDX if possible:
> 
> Currently the TDP MMU hooks are called depending whether the page table type
> is private (or mirrored whatever), but I think conceptually, we should
> decide whether to call TDP MMU hooks based on whether faulting GPA is
> private, _AND_ when the hook is available.
> 
> https://lore.kernel.org/lkml/5e8119c0-31f5-4aa9-a496-4ae10bd745a3@intel.com/
> 
> If invoking SNP RMP commands is feasible in TDP MMU hooks,

Feasible.  Yes.  Desirable?  No.  Either KVM tracks the state of the physical page
using the guest_memfd inode, or KVM _guarantees_ the NPT mappings _never_ get
dropped, including during intra-host migration.  E.g. to support intra-host
migration of TDX VMs, KVM is pretty much forced to transer the S-EPT tables as-is,
which is ugly and painful (though performant).  We could do the same for NPT, but
there would need to be massive performance benefits to justify the complexity.

> then I think there's value of letting SNP code to use them too.  And we can
> simply split one patch out to only add the TDP MMU hooks for SNP to land
> first.

  reply	other threads:[~2024-05-21  0:30 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-01  8:51 [PATCH v15 00/20] Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support Michael Roth
2024-05-01  8:51 ` [PATCH v15 01/20] Revert "KVM: x86: Add gmem hook for determining max NPT mapping level" Michael Roth
2024-05-01  8:51 ` [PATCH v15 02/20] KVM: x86: Add hook for determining max NPT mapping level Michael Roth
2024-05-02 23:11   ` Isaku Yamahata
2024-05-07 17:48   ` Paolo Bonzini
2024-08-01 17:39   ` [PATCH] Fixes: f32fb32820b1 ("KVM: x86: Add hook for determining max NPT mapping level") Ackerley Tng
2024-08-01 17:57     ` Sean Christopherson
2024-08-01 17:59       ` Yosry Ahmed
2024-08-01 18:15     ` Paolo Bonzini
2024-05-01  8:51 ` [PATCH v15 03/20] KVM: SEV: Select KVM_GENERIC_PRIVATE_MEM when CONFIG_KVM_AMD_SEV=y Michael Roth
2024-05-01  8:51 ` [PATCH v15 04/20] KVM: SEV: Add initial SEV-SNP support Michael Roth
2024-05-01  8:51 ` [PATCH v15 05/20] KVM: SEV: Add KVM_SEV_SNP_LAUNCH_START command Michael Roth
2024-05-01  8:51 ` [PATCH v15 06/20] KVM: SEV: Add KVM_SEV_SNP_LAUNCH_UPDATE command Michael Roth
2024-05-01  8:51 ` [PATCH v15 07/20] KVM: SEV: Add KVM_SEV_SNP_LAUNCH_FINISH command Michael Roth
2024-05-01  8:51 ` [PATCH v15 08/20] KVM: SEV: Add support to handle GHCB GPA register VMGEXIT Michael Roth
2024-05-01  8:51 ` [PATCH v15 09/20] KVM: SEV: Add support to handle MSR based Page State Change VMGEXIT Michael Roth
2024-05-16  8:28   ` Binbin Wu
2024-05-16 17:23     ` Paolo Bonzini
2024-05-21  0:49       ` Binbin Wu
2024-05-21 21:49         ` Michael Roth
2024-05-27 12:25           ` Binbin Wu
2024-05-28 10:39             ` Paolo Bonzini
2024-05-29 20:02               ` Sean Christopherson
2024-05-31  1:22                 ` Binbin Wu
2024-05-31 13:10                   ` Paolo Bonzini
2024-05-30 16:47           ` Zhi Wang
2024-05-01  8:52 ` [PATCH v15 10/20] KVM: SEV: Add support to handle " Michael Roth
2024-05-01  8:52 ` [PATCH v15 11/20] KVM: SEV: Add support to handle RMP nested page faults Michael Roth
2024-05-01  8:52 ` [PATCH v15 12/20] KVM: SEV: Support SEV-SNP AP Creation NAE event Michael Roth
2024-05-01  8:52 ` [PATCH v15 13/20] KVM: SEV: Implement gmem hook for initializing private pages Michael Roth
2024-05-20 10:16   ` Huang, Kai
2024-05-20 17:35     ` Sean Christopherson
2024-05-20 21:57       ` Huang, Kai
2024-05-20 23:15         ` Sean Christopherson
2024-05-20 23:41           ` Huang, Kai
2024-05-21  0:30             ` Sean Christopherson [this message]
2024-05-20 19:14     ` Isaku Yamahata
2024-05-01  8:52 ` [PATCH v15 14/20] KVM: SEV: Implement gmem hook for invalidating " Michael Roth
2024-05-01  8:52 ` [PATCH v15 15/20] KVM: x86: Implement hook for determining max NPT mapping level Michael Roth
2024-05-01  8:52 ` [PATCH v15 16/20] KVM: SEV: Avoid WBINVD for HVA-based MMU notifications for SNP Michael Roth
2024-05-01  8:52 ` [PATCH v15 17/20] KVM: SVM: Add module parameter to enable SEV-SNP Michael Roth
2024-05-01  8:52 ` [PATCH v15 18/20] KVM: SEV: Provide support for SNP_GUEST_REQUEST NAE event Michael Roth
2024-05-01  8:52 ` [PATCH v15 19/20] KVM: SEV: Provide support for SNP_EXTENDED_GUEST_REQUEST " Michael Roth
2024-05-13 23:48   ` Sean Christopherson
2024-05-14  2:51     ` Michael Roth
2024-05-14 14:36       ` Sean Christopherson
2024-05-15  1:25         ` [PATCH] KVM: SEV: Replace KVM_EXIT_VMGEXIT with KVM_EXIT_SNP_REQ_CERTS Michael Roth
2024-08-16 21:50           ` Dionna Amalie Glaze
2024-08-16 21:58             ` Dionna Amalie Glaze
2024-05-01  8:52 ` [PATCH v15 20/20] crypto: ccp: Add the SNP_VLEK_LOAD command Michael Roth
2024-05-07 18:04 ` [PATCH v15 00/20] Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support Paolo Bonzini
2024-05-07 18:14   ` Michael Roth
2024-05-10  2:34     ` Michael Roth
2024-05-10  1:58 ` [PATCH v15 21/23] KVM: MMU: Disable fast path for private memslots Michael Roth
2024-05-10  1:58   ` [PATCH v15 22/23] KVM: SEV: Fix return code interpretation for RMP nested page faults Michael Roth
2024-05-10 13:58     ` Sean Christopherson
2024-05-10 15:36       ` Michael Roth
2024-05-10 16:01       ` Paolo Bonzini
2024-05-10 16:37         ` Michael Roth
2024-05-10 16:59           ` Paolo Bonzini
2024-05-10 17:25             ` Paolo Bonzini
2024-05-14  8:10             ` Borislav Petkov
2024-05-10  1:58   ` [PATCH v15 23/23] KVM: SEV: Fix PSC handling for SMASH/UNSMASH and partial update ops Michael Roth
2024-05-10 17:09     ` Paolo Bonzini
2024-05-10 19:08       ` Michael Roth
2024-05-10 13:47   ` [PATCH v15 21/23] KVM: MMU: Disable fast path for private memslots Sean Christopherson
2024-05-10 13:50     ` Paolo Bonzini
2024-05-10 15:27       ` Michael Roth
2024-05-10 15:59         ` Sean Christopherson
2024-05-10 17:47           ` Isaku Yamahata

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=ZkvrFw1QMtImegQD@google.com \
    --to=seanjc@google.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=dovmurik@linux.ibm.com \
    --cc=hpa@zytor.com \
    --cc=isaku.yamahata@gmail.com \
    --cc=jarkko@kernel.org \
    --cc=jmattson@google.com \
    --cc=jroedel@suse.de \
    --cc=kai.huang@intel.com \
    --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=michael.roth@amd.com \
    --cc=mingo@redhat.com \
    --cc=nikunj.dadhania@amd.com \
    --cc=pankaj.gupta@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pgonda@google.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=rientjes@google.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.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 \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.