linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Maxim Levitsky <mlevitsk@redhat.com>
To: Wei Huang <wei.huang2@amd.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	vkuznets@redhat.com, seanjc@google.com, wanpengli@tencent.com,
	jmattson@google.com, joro@8bytes.org, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com
Subject: Re: [PATCH v3 0/3] SVM 5-level page table support
Date: Mon, 23 Aug 2021 21:06:51 +0300	[thread overview]
Message-ID: <9d982f1a5e3b57780445aadd08fcb5315f72cab9.camel@redhat.com> (raw)
In-Reply-To: <20210823151549.rkkrktvtpu6yapmd@weiserver.amd.com>

On Mon, 2021-08-23 at 10:15 -0500, Wei Huang wrote:
> On 08/23 12:20, Maxim Levitsky wrote:
> > On Thu, 2021-08-19 at 18:43 +0200, Paolo Bonzini wrote:
> > > On 18/08/21 18:55, Wei Huang wrote:
> > > > This patch set adds 5-level page table support for AMD SVM. When the
> > > > 5-level page table is enabled on host OS, the nested page table for guest
> > > > VMs will use the same format as host OS (i.e. 5-level NPT). These patches
> > > > were tested with various combination of different settings and test cases
> > > > (nested/regular VMs, AMD64/i686 kernels, kvm-unit-tests, etc.)
> > > > 
> > > > v2->v3:
> > > >   * Change the way of building root_hpa by following the existing flow (Sean)
> > > > 
> > > > v1->v2:
> > > >   * Remove v1's arch-specific get_tdp_level() and add a new parameter,
> > > >     tdp_forced_root_level, to allow forced TDP level (Sean)
> > > >   * Add additional comment on tdp_root table chaining trick and change the
> > > >     PML root table allocation code (Sean)
> > > >   * Revise Patch 1's commit msg (Sean and Jim)
> > > > 
> > > > Thanks,
> > > > -Wei
> > > > 
> > > > Wei Huang (3):
> > > >    KVM: x86: Allow CPU to force vendor-specific TDP level
> > > >    KVM: x86: Handle the case of 5-level shadow page table
> > > >    KVM: SVM: Add 5-level page table support for SVM
> > > > 
> > > >   arch/x86/include/asm/kvm_host.h |  6 ++--
> > > >   arch/x86/kvm/mmu/mmu.c          | 56 ++++++++++++++++++++++-----------
> > > >   arch/x86/kvm/svm/svm.c          | 13 ++++----
> > > >   arch/x86/kvm/vmx/vmx.c          |  3 +-
> > > >   4 files changed, 49 insertions(+), 29 deletions(-)
> > > > 
> > > 
> > > Queued, thanks, with NULL initializations according to Tom's review.
> > > 
> > > Paolo
> > > 
> > 
> > Hi,
> > Yesterday while testing my SMM patches, I noticed a minor issue: 
> > It seems that this patchset breaks my 32 bit nested VM testcase with NPT=0.
> > 
> 
> Could you elaborate the detailed setup? NPT=0 for KVM running on L1?
> Which VM is 32bit - L1 or L2?

NPT=0, L1 and L2 were 32 bit PAE VMs. The test was done to see how well
this setup deals with SMM mode entry/exits with SMM generated by L1 guest,
and see if I have any PDPTR related shenanigans.

I disabled the TDP MMU for now, although in this setup it won't be used anyway.

BIOS was seabios, patched to use PAE itself during bootm, as well in SMM.
(from https://mail.coreboot.org/pipermail/seabios/2015-September/009788.html, patch applied by hand)

Failure was immediate without my hack - L1 died as soon as L2 was started due to an assert in
this code.


Best regards,
	Maxim Levitsky
> 
> Thanks,
> -Wei
> 
> > This hack makes it work again for me (I don't yet use TDP mmu).
> > 
> > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > index caa3f9aee7d1..c25e0d40a620 100644
> > --- a/arch/x86/kvm/mmu/mmu.c
> > +++ b/arch/x86/kvm/mmu/mmu.c
> > @@ -3562,7 +3562,7 @@ static int mmu_alloc_special_roots(struct kvm_vcpu *vcpu)
> >             mmu->shadow_root_level < PT64_ROOT_4LEVEL)
> >                 return 0;
> >  
> > -       if (mmu->pae_root && mmu->pml4_root && mmu->pml5_root)
> > +       if (mmu->pae_root && mmu->pml4_root)
> >                 return 0;
> >  
> >         /*
> > 
> > 
> > 
> > Best regards,
> > 	Maxim Levitsky
> > 



      parent reply	other threads:[~2021-08-23 18:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18 16:55 [PATCH v3 0/3] SVM 5-level page table support Wei Huang
2021-08-18 16:55 ` [PATCH v3 1/3] KVM: x86: Allow CPU to force vendor-specific TDP level Wei Huang
2021-08-18 16:55 ` [PATCH v3 2/3] KVM: x86: Handle the case of 5-level shadow page table Wei Huang
2021-08-18 17:15   ` Sean Christopherson
2021-08-19 16:36     ` Paolo Bonzini
2021-08-18 18:00   ` Tom Lendacky
2021-08-18 16:55 ` [PATCH v3 3/3] KVM: SVM: Add 5-level page table support for SVM Wei Huang
2021-08-18 17:32   ` Sean Christopherson
2021-08-19 16:38     ` Paolo Bonzini
2021-08-19 16:43 ` [PATCH v3 0/3] SVM 5-level page table support Paolo Bonzini
2021-08-23  9:20   ` Maxim Levitsky
2021-08-23 15:15     ` Wei Huang
2021-08-23 16:10       ` Sean Christopherson
2021-08-23 18:10         ` Maxim Levitsky
2021-08-23 18:06       ` Maxim Levitsky [this message]

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=9d982f1a5e3b57780445aadd08fcb5315f72cab9.camel@redhat.com \
    --to=mlevitsk@redhat.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=wei.huang2@amd.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 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).