All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Yang Weijiang <weijiang.yang@intel.com>
Cc: pbonzini@redhat.com, kvm@vger.kernel.org
Subject: Re: [kvm-unit-tests PATCH] x86/access: Fixed test stuck issue on new 52bit machine
Date: Tue, 12 Jan 2021 09:01:43 -0800	[thread overview]
Message-ID: <X/3V92hO1Sw1IdfZ@google.com> (raw)
In-Reply-To: <20210112090421.GA2614@local-michael-cet-test.sh.intel.com>

On Tue, Jan 12, 2021, Yang Weijiang wrote:
> On Mon, Jan 11, 2021 at 02:25:59PM -0800, Sean Christopherson wrote:
> > On Sun, Jan 10, 2021, Yang Weijiang wrote:
> > > When the application is tested on a machine with 52bit-physical-address, the
> > > synthesized 52bit GPA triggers EPT(4-Level) fast_page_fault infinitely.
> > 
> > That doesn't sound right, KVM should use 5-level EPT if guest maxpa > 48.
> > Hmm, unless the CPU doesn't support 5-level EPT, but I didn't think such CPUs
> > (maxpa=52 w/o 5-level EPT) existed?  Ah, but it would be possible with nested
> > VMX, and initial KVM 5-level support didn't allow nested 5-level EPT.  Any
> > chance you're running this test in a VM with 5-level EPT disabled, but maxpa=52?
> >
> Hi, Sean,
> Thanks for the reply!
> I use default settings of the unit-test + 5.2.0 QEMU + 5.10 kernel, in

The default settings are supposed to set guest.MAXPA = host.MAXPA.  At least, I
assume that's the purpose of '-cpu max'.  Maybe your copy of kvm-unit-tests'
x86/unittests.cfg is stale?

  [access]
  file = access.flat
  arch = x86_64
  extra_params = -cpu max
  timeout = 180

> this case, QEMU uses cpu->phys_bits==40, so the guest's PA=40bit and
> LA=57bit, hence 5-level EPT is not enabled. My physical machine is PA=52
> and LA=57 as can checked from cpuid:
> cpuid -1r -l 0x80000008 -s 0
> CPU:
>    0x80000008 0x00: eax=0x00003934 ...
> There're two other ways to w/a this issue: 1) change the QEMU params to
> to extra_params = -cpu host,host-phys-bits, so guest's PA=52 and LA=57,
> this will enable 5-level EPT, meanwhile, it escapes the problematic GPA
> by adding AC_*_BIT51_MASK in invalid_mask.
> 
> 2) add allow_smaller_maxphyaddr=1 to kvm-intel module.

Setting allow_smaller_maxphyaddr=1 is the correct answer.

  reply	other threads:[~2021-01-12 17:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-10  9:19 [kvm-unit-tests PATCH] x86/access: Fixed test stuck issue on new 52bit machine Yang Weijiang
2021-01-11 22:25 ` Sean Christopherson
2021-01-12  9:04   ` Yang Weijiang
2021-01-12 17:01     ` Sean Christopherson [this message]
2021-01-13  9:07       ` Yang Weijiang

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=X/3V92hO1Sw1IdfZ@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=weijiang.yang@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 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.