All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Xiaoyao Li <xiaoyao.li@intel.com>
Cc: kvm@vger.kernel.org, Gerd Hoffmann <kraxel@redhat.com>,
	 Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [PATCH v4 0/2] kvm/cpuid: set proper GuestPhysBits in CPUID.0x80000008
Date: Mon, 15 Apr 2024 07:58:21 -0700	[thread overview]
Message-ID: <Zh1AjYMP-v1z3Xp2@google.com> (raw)
In-Reply-To: <627a61bf-de07-43a7-bb4a-9539673674b2@intel.com>

On Mon, Apr 15, 2024, Xiaoyao Li wrote:
> On 4/12/2024 11:48 PM, Sean Christopherson wrote:
> > On Fri, Apr 12, 2024, Xiaoyao Li wrote:
> > If we go deep enough, it becomes a functional problem.  It's not even _that_
> > ridiculous/contrived :-)
> > 
> > L1 KVM is still aware that the real MAXPHYADDR=52, and so there are no immediate
> > issues with reserved bits at that level.
> > 
> > But L1 userspace will unintentionally configure L2 with CPUID.0x8000_0008.EAX[7:0]=48,
> > and so L2 KVM will incorrectly think bits 51:48 are reserved.  If both L0 and L1
> > are using TDP, neither L0 nor L1 will intercept #PF.  And because L1 userspace
> > was told MAXPHYADDR=48, it won't know that KVM needs to be configured with
> > allow_smaller_maxphyaddr=true in order for the setup to function correctly.
> 
> In this case, a) L1 userspace was told by L1 KVM that MAXPHYADDR = 48 via
> KVM_GET_SUPPORTED_CPUID. But b) L1 userspace gets MAXPHYADDR = 52 by
> executing CPUID itself.

KVM can't assume userspace will do raw CPUID.

  reply	other threads:[~2024-04-15 14:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-13 12:58 [PATCH v4 0/2] kvm/cpuid: set proper GuestPhysBits in CPUID.0x80000008 Gerd Hoffmann
2024-03-13 12:58 ` [PATCH v4 1/2] kvm/cpuid: remove GuestPhysBits code Gerd Hoffmann
2024-03-13 12:58 ` [PATCH v4 2/2] kvm/cpuid: set proper GuestPhysBits in CPUID.0x80000008 Gerd Hoffmann
2024-04-10  0:19 ` [PATCH v4 0/2] " Sean Christopherson
2024-04-12  7:03   ` Xiaoyao Li
2024-04-12 15:48     ` Sean Christopherson
2024-04-15  6:17       ` Xiaoyao Li
2024-04-15 14:58         ` Sean Christopherson [this message]
2024-04-16  8:47           ` Xiaoyao Li
2024-04-16 14:14             ` Sean Christopherson

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=Zh1AjYMP-v1z3Xp2@google.com \
    --to=seanjc@google.com \
    --cc=kraxel@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=thomas.lendacky@amd.com \
    --cc=xiaoyao.li@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.