linux-coco.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Brijesh Singh <brijesh.singh@amd.com>
To: Sean Christopherson <seanjc@google.com>
Cc: brijesh.singh@amd.com, x86@kernel.org,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org,
	linux-coco@lists.linux.dev, linux-mm@kvack.org,
	linux-crypto@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Joerg Roedel <jroedel@suse.de>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>,
	Andy Lutomirski <luto@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Sergio Lopez <slp@redhat.com>, Peter Gonda <pgonda@google.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	David Rientjes <rientjes@google.com>,
	Dov Murik <dovmurik@linux.ibm.com>,
	Tobin Feldman-Fitzthum <tobin@ibm.com>,
	Borislav Petkov <bp@alien8.de>,
	Michael Roth <michael.roth@amd.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	tony.luck@intel.com, npmccallum@redhat.com,
	brijesh.ksingh@gmail.com
Subject: Re: [PATCH Part2 RFC v4 27/40] KVM: X86: Add kvm_x86_ops to get the max page level for the TDP
Date: Fri, 16 Jul 2021 15:41:56 -0500	[thread overview]
Message-ID: <1ed3c439-a02c-7182-b140-32cddd5e4f34@amd.com> (raw)
In-Reply-To: <YPHbxAVbuFk6Xtkj@google.com>


On 7/16/21 2:19 PM, Sean Christopherson wrote:
> On Wed, Jul 07, 2021, Brijesh Singh wrote:
>> When running an SEV-SNP VM, the sPA used to index the RMP entry is
>> obtained through the TDP translation (gva->gpa->spa). The TDP page
>> level is checked against the page level programmed in the RMP entry.
>> If the page level does not match, then it will cause a nested page
>> fault with the RMP bit set to indicate the RMP violation.
>>
>> To keep the TDP and RMP page level's in sync, the KVM fault handle
>> kvm_handle_page_fault() will call get_tdp_max_page_level() to get
>> the maximum allowed page level so that it can limit the TDP level.
>>
>> In the case of SEV-SNP guest, the get_tdp_max_page_level() will consult
>> the RMP table to compute the maximum allowed page level for a given
>> GPA.
>>
>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>> ---
>>  arch/x86/include/asm/kvm_host.h |  1 +
>>  arch/x86/kvm/mmu/mmu.c          |  6 ++++--
>>  arch/x86/kvm/svm/sev.c          | 20 ++++++++++++++++++++
>>  arch/x86/kvm/svm/svm.c          |  1 +
>>  arch/x86/kvm/svm/svm.h          |  1 +
>>  arch/x86/kvm/vmx/vmx.c          |  8 ++++++++
>>  6 files changed, 35 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
>> index 188110ab2c02..cd2e19e1d323 100644
>> --- a/arch/x86/include/asm/kvm_host.h
>> +++ b/arch/x86/include/asm/kvm_host.h
>> @@ -1384,6 +1384,7 @@ struct kvm_x86_ops {
>>  
>>  	void (*vcpu_deliver_sipi_vector)(struct kvm_vcpu *vcpu, u8 vector);
>>  	void *(*alloc_apic_backing_page)(struct kvm_vcpu *vcpu);
>> +	int (*get_tdp_max_page_level)(struct kvm_vcpu *vcpu, gpa_t gpa, int max_level);
> This is a poor name.  The constraint comes from the RMP, not TDP, and technically
> speaking applies to all forms of paging.  It just happens to be relevant only to
> TDP because NPT is required for SNP.  And KVM already incorporates the max TDP
> level in kvm_configure_mmu().

Noted.


>
> Regarding the params, I'd much prefer to have this take "struct kvm *kvm" instead
> of the vCPU.  It obviously doesn't change the functionality in any way, but I'd
> like it to be clear to readers that the adjustment is tied to the VM, not the vCPU.

Noted.


> I think I'd also vote to drop @max_level and make this a pure constraint input as
> opposed to an adjuster.


Noted.

> Another option would be to drop the kvm_x86_ops hooks entirely and call
> snp_lookup_page_in_rmptable() directly from MMU code.  That would require tracking
> that a VM is SNP-enabled in arch code, but I'm pretty sure info has already bled
> into common KVM in one form or another.

I would prefer this as it eliminates some of the other unnecessary call
sites. Unfortunately, currently there is no generic way to know if its
an SEV guest (outside the svm/*).  So far there was no need as such but
with SNP having such information would help. Should we extend the
'struct kvm' to include a new field that can be used to determine the
guest type. Something like

enum {

   GUEST_TYPE_SEV,

   GUEST_TYPE_SEV_ES,

   GUEST_TYPE_SEV_SNP,

};

struct kvm {

   ...

  u64 enc_type;

};

bool kvm_guest_enc_type(struct kvm *kvm, enum type); {

    return !!kvm->enc_type & type;

}

The mmu.c can then call kvm_guest_enc_type() to check if its SNP guest
and use the SNP lookup directly to determine the pagesize.


>
>>  };
>>  
>>  struct kvm_x86_nested_ops {
>> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
>> index 0144c40d09c7..7991ffae7b31 100644
>> --- a/arch/x86/kvm/mmu/mmu.c
>> +++ b/arch/x86/kvm/mmu/mmu.c
>> @@ -3781,11 +3781,13 @@ static int direct_page_fault(struct kvm_vcpu *vcpu, gpa_t gpa, u32 error_code,
>>  static int nonpaging_page_fault(struct kvm_vcpu *vcpu, gpa_t gpa,
>>  				u32 error_code, bool prefault)
>>  {
>> +	int max_level = kvm_x86_ops.get_tdp_max_page_level(vcpu, gpa, PG_LEVEL_2M);
> This is completely bogus, nonpaging_page_fault() is used iff TDP is disabled.

Ah, I totally missed it.


>> +
>>  	pgprintk("%s: gva %lx error %x\n", __func__, gpa, error_code);
>>  
>>  	/* This path builds a PAE pagetable, we can map 2mb pages at maximum. */
>>  	return direct_page_fault(vcpu, gpa & PAGE_MASK, error_code, prefault,
>> -				 PG_LEVEL_2M, false);
>> +				 max_level, false);
>>  }
>>  
>>  int kvm_handle_page_fault(struct kvm_vcpu *vcpu, u64 error_code,
>> @@ -3826,7 +3828,7 @@ int kvm_tdp_page_fault(struct kvm_vcpu *vcpu, gpa_t gpa, u32 error_code,
>>  {
>>  	int max_level;
>>  
>> -	for (max_level = KVM_MAX_HUGEPAGE_LEVEL;
>> +	for (max_level = kvm_x86_ops.get_tdp_max_page_level(vcpu, gpa, KVM_MAX_HUGEPAGE_LEVEL);
> This is unnecessary.  The max mapping level is computed by factoring in all
> constraints, of which there are many.  In this case, KVM is consulting the guest's
> MTRR configuration to avoid creating a page that spans different memtypes (because
> the guest MTRRs are effectively represented in the TDP PTE).  SNP's RMP constraints
> have no relevance to the MTRR constraint, or any other constraint for that matter.
>
> TL;DR: the RMP constraint belong in kvm_mmu_max_mapping_level() and nowhere else.
> I would go so far as to argue it belong in host_pfn_mapping_level(), after the
> call to lookup_address_in_mm().


I agree with you; One of the case which I was trying to cover is what if
we do a pre-fault and while generating the prefault we can tell the
handler our max page level; The example is: "Guest issues a page state
transition request to add the page as 2mb". We execute the below steps
to fulfill the request

* create a prefault with a max_level set to 2mb.

* the fault handler may find that it cannot use the large page in the
npt, and it may default to 4k

* read the page-size from the npt;  use the npt pagesize in the rmptable
instead of the guest requested page-size.

We keep the NPT and RMP in sync after the page state change is completed
and avoid any extra RMP fault due to the size mismatch etc.


>>  	     max_level > PG_LEVEL_4K;
>>  	     max_level--) {
>>  		int page_num = KVM_PAGES_PER_HPAGE(max_level);
>> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
>> index 3f8824c9a5dc..fd2d00ad80b7 100644
>> --- a/arch/x86/kvm/svm/sev.c
>> +++ b/arch/x86/kvm/svm/sev.c
>> @@ -3206,3 +3206,23 @@ struct page *snp_safe_alloc_page(struct kvm_vcpu *vcpu)
>>  
>>  	return pfn_to_page(pfn);
>>  }
>> +
>> +int sev_get_tdp_max_page_level(struct kvm_vcpu *vcpu, gpa_t gpa, int max_level)
>> +{
>> +	struct rmpentry *e;
>> +	kvm_pfn_t pfn;
>> +	int level;
>> +
>> +	if (!sev_snp_guest(vcpu->kvm))
> I can't tell if this check is correct.  Per the APM:
>
>   When SEV-SNP is enabled globally, the processor places restrictions on all memory
>   accesses based on the contents of the RMP, whether the accesses are performed by
>   the hypervisor, a legacy guest VM, a non-SNP guest VM or an SNP-active guest VM.
>   The processor may perform one or more of the following checks depending on the
>   context of the access:
>
>   ...
>
>   Page-Size: Checks that the following conditions are met:
>     - If the nested page table indicates a 2MB or 1GB page size, the Page_Size field
>       of the RMP entry of the target page is 1.
>     - If the nested page table indicates a 4KB page size, the Page_Size field of the
>       RMP entry of the target page is 0.
>
> The Page-Size bullet does not have any qualifiers about the NPT checks applying
> only to SNP guests.  The Hypervisor-Owned bullet implies that unassigned pages
> do not need to have identical sizes, but it's not clear whether or not so called
> "Hypervisor-Owned" pages override the nested page tables.
>
> Table 15.36 is similarly vague:
>
>   Assigned Flag indicating that the system physical page is assigned to a guest
>   or to the AMD-SP.
>     0: Owned by the hypervisor
>     1: Owned by a guest or the AMD-SP
>
> My assumption is that all of the "guest owned" stuff really means "SNP guest owned",
> e.g. section 15.36.5 says "The hypervisor manages the SEV-SNP security attributes of
> pages assigned to SNP-active guests by altering the RMP entries of those pages", but
> that's not at all clear throughout most of the RMP documentation.
>
> Regardless of the actual behavior, the APM needs serious cleanup on the aforementioned
> sections.  E.g. as written, the "processor may perform one or more of the following
> checks depending on the context of the access" verbiage basically gives the CPU carte
> blanche to do whatever the hell it wants.

I'll raise your concern to the documentation folks so that they clarify
that the page-size check is applicable to the SNP active guests only.


>> +		return max_level;
>> +
>> +	pfn = gfn_to_pfn(vcpu->kvm, gpa_to_gfn(gpa));
>> +	if (is_error_noslot_pfn(pfn))
>> +		return max_level;
>> +
>> +	e = snp_lookup_page_in_rmptable(pfn_to_page(pfn), &level);
> Assuming pfn is backed by struct page is broken, at least given the existing
> call sites..  It might hold true that only struct page pfns are covered by the
> RMP, but assuming pfn_to_page() will return a valid pointer here is completely
> wrong.  Unless I'm missing something, taking a struct page anywhere in the RMP
> helpers is at best sketchy and at worst broken in and of itself.  IMO, the RMP
> code should always take a raw PFN and do the necessary checks before assuming
> anything about the PFN.  At a glance, the only case that needs additional checks
> is the page_to_virt() logic in rmpupdate().

I agree. Dave also hinted the similar feedback. In next version of the
patch I will stick to use the pfn and then SNP lookup with do the
required checking.


>> +	if (unlikely(!e))
>> +		return max_level;
>> +
>> +	return min_t(uint32_t, level, max_level);
> As the APM is currently worded, this is wrong, and the whole "tdp_max_page_level"
> name is wrong.  As noted above, the Page-Size bullet points states that 2mb/1gb
> pages in the NPT _must_ have RMP.page_size=1, and 4kb pages in the NPT _must_
> have RMP.page_size=0.  That means that the RMP adjustment is not a constraint,
> it's an exact requirement.  Specifically, if the RMP is a 2mb page then KVM must
> install a 2mb (or 1gb) page.  Maybe it works because KVM will PSMASH the RMP
> after installing a bogus 4kb NPT and taking an RMP violation, but that's a very
> convoluted and sub-optimal solution.

This is why I was passing the preferred max_level in the pre-fault
handle then later query the npt level; use the npt level in the RMP to
make sure they are in sync.

There is yet another reason why we can't avoid the PSMASH after doing
everything to ensure that NPT and RMP are in sync. e.g if NPT and RMP
are programmed with 2mb size but the guest tries to PVALIDATE the page
as a 4k. In that case, we will see #NPF with page size mismatch and have
to perform psmash.


>
> That other obvious bug is that this doesn't play nice with 1gb pages.  A 2mb RMP
> entry should _not_ force KVM to use a 2mb page instead of a 1gb page.
>
>> +}

  reply	other threads:[~2021-07-16 20:42 UTC|newest]

Thread overview: 176+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-07 18:35 [PATCH Part2 RFC v4 00/40] Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support Brijesh Singh
2021-07-07 18:35 ` [PATCH Part2 RFC v4 01/40] KVM: SVM: Add support to handle AP reset MSR protocol Brijesh Singh
2021-07-14 20:17   ` Sean Christopherson
2021-07-15  7:39     ` Joerg Roedel
2021-07-15 13:42     ` Tom Lendacky
2021-07-15 15:45       ` Sean Christopherson
2021-07-15 17:05         ` Tom Lendacky
2021-07-07 18:35 ` [PATCH Part2 RFC v4 02/40] KVM: SVM: Provide the Hypervisor Feature support VMGEXIT Brijesh Singh
2021-07-14 20:37   ` Sean Christopherson
2021-07-14 21:00     ` Brijesh Singh
2021-07-07 18:35 ` [PATCH Part2 RFC v4 03/40] x86/cpufeatures: Add SEV-SNP CPU feature Brijesh Singh
2021-07-07 18:35 ` [PATCH Part2 RFC v4 04/40] x86/sev: Add the host SEV-SNP initialization support Brijesh Singh
2021-07-14 21:07   ` Sean Christopherson
2021-07-14 22:02     ` Brijesh Singh
2021-07-14 22:06       ` Sean Christopherson
2021-07-14 22:11         ` Brijesh Singh
2021-07-07 18:35 ` [PATCH Part2 RFC v4 05/40] x86/sev: Add RMP entry lookup helpers Brijesh Singh
2021-07-15 18:37   ` Sean Christopherson
2021-07-15 19:28     ` Brijesh Singh
2021-07-16 17:22       ` Brijesh Singh
2021-07-20 22:06         ` Sean Christopherson
2021-07-20 23:10           ` Brijesh Singh
2021-07-07 18:35 ` [PATCH Part2 RFC v4 06/40] x86/sev: Add helper functions for RMPUPDATE and PSMASH instruction Brijesh Singh
2021-07-12 18:44   ` Peter Gonda
2021-07-12 19:00     ` Dave Hansen
2021-07-15 18:56       ` Sean Christopherson
2021-07-15 19:08         ` Dave Hansen
2021-07-15 19:18           ` Sean Christopherson
2021-07-07 18:35 ` [PATCH Part2 RFC v4 07/40] x86/sev: Split the physmap when adding the page in RMP table Brijesh Singh
2021-07-14 22:25   ` Sean Christopherson
2021-07-15 17:05     ` Brijesh Singh
2021-07-15 17:51       ` Sean Christopherson
2021-07-15 18:14         ` Brijesh Singh
2021-07-15 18:39           ` Sean Christopherson
2021-07-15 19:38             ` Brijesh Singh
2021-07-15 22:01               ` Sean Christopherson
2021-07-15 22:11                 ` Brijesh Singh
2021-07-30 11:31               ` Vlastimil Babka
2021-07-30 16:10                 ` Brijesh Singh
2021-07-07 18:35 ` [PATCH Part2 RFC v4 08/40] x86/traps: Define RMP violation #PF error code Brijesh Singh
2021-07-15 19:02   ` Sean Christopherson
2021-07-15 19:16     ` Dave Hansen
2021-07-07 18:35 ` [PATCH Part2 RFC v4 09/40] x86/fault: Add support to dump RMP entry on fault Brijesh Singh
2021-07-07 19:21   ` Dave Hansen
2021-07-08 15:02     ` Brijesh Singh
2021-07-08 15:30       ` Dave Hansen
2021-07-08 16:48         ` Brijesh Singh
2021-07-08 16:58           ` Dave Hansen
2021-07-08 17:11             ` Brijesh Singh
2021-07-08 17:15               ` Dave Hansen
2021-07-07 18:35 ` [PATCH Part2 RFC v4 10/40] x86/fault: Add support to handle the RMP fault for user address Brijesh Singh
2021-07-08 16:16   ` Dave Hansen
2021-07-12 15:43     ` Brijesh Singh
2021-07-12 16:00       ` Dave Hansen
2021-07-12 16:11         ` Brijesh Singh
2021-07-12 16:15           ` Dave Hansen
2021-07-12 16:24             ` Brijesh Singh
2021-07-12 16:29               ` Dave Hansen
2021-07-12 16:49                 ` Brijesh Singh
2021-07-15 21:53                   ` Sean Christopherson
2021-07-30 16:00   ` Vlastimil Babka
2021-07-30 16:31     ` Dave Hansen
2021-07-07 18:35 ` [PATCH Part2 RFC v4 11/40] crypto:ccp: Define the SEV-SNP commands Brijesh Singh
2021-07-07 18:35 ` [PATCH Part2 RFC v4 12/40] crypto: ccp: Add support to initialize the AMD-SP for SEV-SNP Brijesh Singh
2021-07-07 18:35 ` [PATCH Part2 RFC v4 13/40] crypto: ccp: Shutdown SNP firmware on kexec Brijesh Singh
2021-07-07 18:35 ` [PATCH Part2 RFC v4 14/40] crypto:ccp: Provide APIs to issue SEV-SNP commands Brijesh Singh
2021-07-08 18:56   ` Dr. David Alan Gilbert
2021-07-07 18:35 ` [PATCH Part2 RFC v4 15/40] crypto: ccp: Handle the legacy TMR allocation when SNP is enabled Brijesh Singh
2021-07-14 13:22   ` Marc Orr
2021-07-14 16:45     ` Brijesh Singh
2021-07-14 18:14       ` Marc Orr
2021-07-15 23:48   ` Sean Christopherson
2021-07-16 12:55     ` Brijesh Singh
2021-07-16 15:35       ` Sean Christopherson
2021-07-16 15:47         ` Brijesh Singh
2021-07-07 18:35 ` [PATCH Part2 RFC v4 16/40] crypto: ccp: Handle the legacy SEV command " Brijesh Singh
2021-07-07 18:35 ` [PATCH Part2 RFC v4 17/40] crypto: ccp: Add the SNP_PLATFORM_STATUS command Brijesh Singh
2021-07-07 18:35 ` [PATCH Part2 RFC v4 18/40] crypto: ccp: Add the SNP_{SET,GET}_EXT_CONFIG command Brijesh Singh
2021-07-07 18:35 ` [PATCH Part2 RFC v4 19/40] crypto: ccp: provide APIs to query extended attestation report Brijesh Singh
2021-07-07 18:35 ` [PATCH Part2 RFC v4 20/40] KVM: SVM: Make AVIC backing, VMSA and VMCB memory allocation SNP safe Brijesh Singh
2021-07-14 13:35   ` Marc Orr
2021-07-14 16:47     ` Brijesh Singh
2021-07-20 18:02   ` Sean Christopherson
2021-08-03 14:38     ` Brijesh Singh
2021-07-07 18:35 ` [PATCH Part2 RFC v4 21/40] KVM: SVM: Add initial SEV-SNP support Brijesh Singh
2021-07-16 18:00   ` Sean Christopherson
2021-07-16 18:46     ` Brijesh Singh
2021-07-16 19:31       ` Sean Christopherson
2021-07-16 21:03         ` Brijesh Singh
2021-07-07 18:35 ` [PATCH Part2 RFC v4 22/40] KVM: SVM: Add KVM_SNP_INIT command Brijesh Singh
2021-07-16 19:33   ` Sean Christopherson
2021-07-16 21:25     ` Brijesh Singh
2021-07-19 20:24       ` Sean Christopherson
2021-07-07 18:35 ` [PATCH Part2 RFC v4 23/40] KVM: SVM: Add KVM_SEV_SNP_LAUNCH_START command Brijesh Singh
2021-07-12 18:45   ` Peter Gonda
2021-07-16 19:43   ` Sean Christopherson
2021-07-16 21:42     ` Brijesh Singh
2021-07-07 18:36 ` [PATCH Part2 RFC v4 24/40] KVM: SVM: Add KVM_SEV_SNP_LAUNCH_UPDATE command Brijesh Singh
2021-07-16 20:01   ` Sean Christopherson
2021-07-16 22:00     ` Brijesh Singh
2021-07-19 20:51       ` Sean Christopherson
2021-07-19 21:34         ` Brijesh Singh
2021-07-19 21:36           ` Brijesh Singh
2021-07-07 18:36 ` [PATCH Part2 RFC v4 25/40] KVM: SVM: Reclaim the guest pages when SEV-SNP VM terminates Brijesh Singh
2021-07-16 20:09   ` Sean Christopherson
2021-07-16 22:16     ` Brijesh Singh
2021-07-17  0:46       ` Sean Christopherson
2021-07-19 12:55         ` Brijesh Singh
2021-07-19 17:18           ` Sean Christopherson
2021-07-19 18:34             ` Brijesh Singh
2021-07-19 19:03               ` Sean Christopherson
2021-07-19 19:14                 ` Sean Christopherson
2021-07-19 19:37                 ` Brijesh Singh
2021-07-20 16:40                   ` Sean Christopherson
2021-07-20 18:23                     ` Brijesh Singh
2021-07-07 18:36 ` [PATCH Part2 RFC v4 26/40] KVM: SVM: Add KVM_SEV_SNP_LAUNCH_FINISH command Brijesh Singh
2021-07-16 20:18   ` Sean Christopherson
2021-07-16 22:48     ` Brijesh Singh
2021-07-19 16:54       ` Sean Christopherson
2021-07-19 18:29         ` Brijesh Singh
2021-07-19 19:14           ` Sean Christopherson
2021-07-19 19:49             ` Brijesh Singh
2021-07-19 20:13               ` Sean Christopherson
2021-07-21 17:53         ` Marc Orr
2021-07-07 18:36 ` [PATCH Part2 RFC v4 27/40] KVM: X86: Add kvm_x86_ops to get the max page level for the TDP Brijesh Singh
2021-07-16 19:19   ` Sean Christopherson
2021-07-16 20:41     ` Brijesh Singh [this message]
2021-07-20 19:38       ` Sean Christopherson
2021-07-20 20:06         ` Brijesh Singh
2021-07-07 18:36 ` [PATCH Part2 RFC v4 28/40] KVM: X86: Introduce kvm_mmu_map_tdp_page() for use by SEV Brijesh Singh
2021-07-16 18:15   ` Sean Christopherson
2021-07-07 18:36 ` [PATCH Part2 RFC v4 29/40] KVM: X86: Introduce kvm_mmu_get_tdp_walk() for SEV-SNP use Brijesh Singh
2021-07-07 18:36 ` [PATCH Part2 RFC v4 30/40] KVM: X86: Define new RMP check related #NPF error bits Brijesh Singh
2021-07-16 20:22   ` Sean Christopherson
2021-07-17  0:34     ` Brijesh Singh
2021-07-07 18:36 ` [PATCH Part2 RFC v4 31/40] KVM: X86: update page-fault trace to log the 64-bit error code Brijesh Singh
2021-07-16 20:25   ` Sean Christopherson
2021-07-17  0:35     ` Brijesh Singh
2021-07-07 18:36 ` [PATCH Part2 RFC v4 32/40] KVM: SVM: Add support to handle GHCB GPA register VMGEXIT Brijesh Singh
2021-07-16 20:45   ` Sean Christopherson
2021-07-17  0:44     ` Brijesh Singh
2021-07-19 20:04       ` Sean Christopherson
2021-07-07 18:36 ` [PATCH Part2 RFC v4 33/40] KVM: SVM: Add support to handle MSR based Page State Change VMGEXIT Brijesh Singh
2021-07-16 21:00   ` Sean Christopherson
2021-07-19 14:19     ` Brijesh Singh
2021-07-19 18:55       ` Sean Christopherson
2021-07-19 19:15         ` Brijesh Singh
2021-08-13 16:32         ` Borislav Petkov
2021-07-07 18:36 ` [PATCH Part2 RFC v4 34/40] KVM: SVM: Add support to handle " Brijesh Singh
2021-07-16 21:14   ` Sean Christopherson
2021-07-19 14:24     ` Brijesh Singh
2021-07-07 18:36 ` [PATCH Part2 RFC v4 35/40] KVM: Add arch hooks to track the host write to guest memory Brijesh Singh
2021-07-19 23:30   ` Sean Christopherson
2021-07-20 15:15     ` Brijesh Singh
2021-07-07 18:36 ` [PATCH Part2 RFC v4 36/40] KVM: X86: Export the kvm_zap_gfn_range() for the SNP use Brijesh Singh
2021-07-07 18:36 ` [PATCH Part2 RFC v4 37/40] KVM: SVM: Add support to handle the RMP nested page fault Brijesh Singh
2021-07-20  0:10   ` Sean Christopherson
2021-07-20 17:55     ` Brijesh Singh
2021-07-20 22:31       ` Sean Christopherson
2021-07-20 23:53         ` Brijesh Singh
2021-07-21 20:15           ` Sean Christopherson
2021-07-07 18:36 ` [PATCH Part2 RFC v4 38/40] KVM: SVM: Provide support for SNP_GUEST_REQUEST NAE event Brijesh Singh
2021-07-19 22:50   ` Sean Christopherson
2021-07-20 14:37     ` Brijesh Singh
2021-07-20 16:28       ` Sean Christopherson
2021-07-20 18:21         ` Brijesh Singh
2021-07-20 22:09           ` Sean Christopherson
2021-07-07 18:36 ` [PATCH Part2 RFC v4 39/40] KVM: SVM: Use a VMSA physical address variable for populating VMCB Brijesh Singh
2021-07-21  0:20   ` Sean Christopherson
2021-07-21 16:26     ` Tom Lendacky
2021-07-07 18:36 ` [PATCH Part2 RFC v4 40/40] KVM: SVM: Support SEV-SNP AP Creation NAE event Brijesh Singh
2021-07-21  0:01   ` Sean Christopherson
2021-07-21 17:47     ` Tom Lendacky
2021-07-21 19:52       ` Sean Christopherson
2021-08-20 14:44         ` Tom Lendacky
2021-07-08 15:40 ` [PATCH Part2 RFC v4 00/40] Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support Dave Hansen

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=1ed3c439-a02c-7182-b140-32cddd5e4f34@amd.com \
    --to=brijesh.singh@amd.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=brijesh.ksingh@gmail.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dovmurik@linux.ibm.com \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=jroedel@suse.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-efi@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=npmccallum@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pgonda@google.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rientjes@google.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=wanpengli@tencent.com \
    --cc=x86@kernel.org \
    --subject='Re: [PATCH Part2 RFC v4 27/40] KVM: X86: Add kvm_x86_ops to get the max page level for the TDP' \
    /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

This is a public inbox, see mirroring instructions
on how to clone and mirror all data and code used for this inbox