From: Sean Christopherson <seanjc@google.com>
To: Tao Su <tao1.su@linux.intel.com>
Cc: Chao Gao <chao.gao@intel.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, Yi Lai <yi1.lai@intel.com>,
Xudong Hao <xudong.hao@intel.com>
Subject: Re: [PATCH] x86/cpu: Add a VMX flag to enumerate 5-level EPT support to userspace
Date: Thu, 11 Jan 2024 08:25:01 -0800 [thread overview]
Message-ID: <ZaAWXSvMgIMkxr50@google.com> (raw)
In-Reply-To: <ZZ9X5anB/HGS8JR6@linux.bj.intel.com>
On Thu, Jan 11, 2024, Tao Su wrote:
> On Wed, Jan 10, 2024 at 08:26:25AM -0800, Sean Christopherson wrote:
> > On Wed, Jan 10, 2024, Chao Gao wrote:
> > > On Tue, Jan 09, 2024 at 04:23:40PM -0800, Sean Christopherson wrote:
> > > >Add a VMX flag in /proc/cpuinfo, ept_5level, so that userspace can query
> > > >whether or not the CPU supports 5-level EPT paging. EPT capabilities are
> > > >enumerated via MSR, i.e. aren't accessible to userspace without help from
> > > >the kernel, and knowing whether or not 5-level EPT is supported is sadly
> > > >necessary for userspace to correctly configure KVM VMs.
> > >
> > > This assumes procfs is enabled in Kconfig and userspace has permission to
> > > access /proc/cpuinfo. But it isn't always true. So, I think it is better to
> > > advertise max addressable GPA via KVM ioctls.
> >
> > Hrm, so the help for PROC_FS says:
> >
> > Several programs depend on this, so everyone should say Y here.
> >
> > Given that this is working around something that is borderline an erratum, I'm
> > inclined to say that userspace shouldn't simply assume the worst if /proc isn't
> > available. Practically speaking, I don't think a "real" VM is likely to be
> > affected; AFAIK, there's no reason for QEMU or any other VMM to _need_ to expose
> > a memslot at GPA[51:48] unless the VM really has however much memory that is
> > (hundreds of terabytes?). And a if someone is trying to run such a massive VM on
> > such a goofy CPU...
>
> It is unusual to assign a huge RAM to guest, but passthrough a device also may trigger
> this issue which we have met, i.e. alloc memslot for the 64bit BAR which can set
> bits[51:48]. BIOS can control the BAR address, e.g. seabios moved 64bit pci window
> to end of address space by using advertised physical bits[1].
Drat. Do you know if these CPUs are going to be productized? We'll still need
something in KVM either way, but whether or not the problems are more or less
limited to funky software setups might influence how we address this.
next prev parent reply other threads:[~2024-01-11 16:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-10 0:23 [PATCH] x86/cpu: Add a VMX flag to enumerate 5-level EPT support to userspace Sean Christopherson
2024-01-10 2:20 ` Tao Su
2024-01-10 13:59 ` Sean Christopherson
2024-01-10 6:16 ` Chao Gao
2024-01-10 16:26 ` Sean Christopherson
2024-01-11 2:52 ` Tao Su
2024-01-11 16:25 ` Sean Christopherson [this message]
2024-01-11 20:02 ` Paolo Bonzini
2024-01-11 21:12 ` Jim Mattson
2024-01-12 1:08 ` Tao Su
2024-01-11 10:13 ` Paolo Bonzini
2024-01-11 16:17 ` Sean Christopherson
2024-02-23 1:35 ` Sean Christopherson
2024-02-26 1:30 ` Xiaoyao Li
2024-02-26 7:11 ` Tao Su
2024-02-26 15:27 ` 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=ZaAWXSvMgIMkxr50@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=tao1.su@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xudong.hao@intel.com \
--cc=yi1.lai@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox