From: Tao Su <tao1.su@linux.intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Chao Gao <chao.gao@intel.com>, Jim Mattson <jmattson@google.com>,
kvm@vger.kernel.org, pbonzini@redhat.com, eddie.dong@intel.com,
xiaoyao.li@intel.com, yuan.yao@linux.intel.com,
yi1.lai@intel.com, xudong.hao@intel.com, chao.p.peng@intel.com
Subject: Re: [PATCH 1/2] x86: KVM: Limit guest physical bits when 5-level EPT is unsupported
Date: Wed, 20 Dec 2023 19:59:38 +0800 [thread overview]
Message-ID: <ZYLXKkd6W5L+Drw/@linux.bj.intel.com> (raw)
In-Reply-To: <ZYG2CDRFlq50siec@google.com>
On Tue, Dec 19, 2023 at 07:26:00AM -0800, Sean Christopherson wrote:
> On Tue, Dec 19, 2023, Chao Gao wrote:
> > On Mon, Dec 18, 2023 at 07:40:11PM -0800, Jim Mattson wrote:
> > >Honestly, I think KVM should just disable EPT if the EPT tables can't
> > >support the CPU's physical address width.
> >
> > Yes, it is an option.
> > But I prefer to allow admin to override this (i.e., admin still can enable EPT
> > via module parameter) because those issues are not new and disabling EPT
> > doesn't prevent QEMU from launching guests w/ smaller MAXPHYADDR.
> >
> > >> Here nothing visible to selftests or QEMU indicates that guest.MAXPHYADDR = 52
> > >> is invalid/incorrect. how can we say selftests are at fault and we should fix
> > >> them?
> > >
> > >In this case, the CPU is at fault, and you should complain to the CPU vendor.
> >
> > Yeah, I agree with you and will check with related team inside Intel.
>
> I agree that the CPU is being weird, but this is technically an architecturally
> legal configuration, and KVM has largely committed to supporting weird setups.
> At some point we have to draw a line when things get too ridiculous, but I don't
> think this particular oddity crosses into absurd territory.
>
> > My point was just this isn't a selftest issue because not all information is
> > disclosed to the tests.
>
> Ah, right, EPT capabilities are in MSRs that userspace can't read.
>
> > And I am afraid KVM as L1 VMM may run into this situation, i.e., only 4-level
> > EPT is supported but MAXPHYADDR is 52. So, KVM needs a fix anyway.
>
> Yes, but forcing emulation for a funky setup is not a good fix. KVM can simply
> constrain the advertised MAXPHYADDR, no?
GPA is controlled by guest, I.e., just install PTE in guest page table, and the
GPAs beyond 48-bits always trigger EPT violation. If KVM does nothing, guest
can’t get #PF when accessing >MAXPHYADDR, which is inconsistent with
architectural behavior. But doing nothing is also an option because userspace
doesn’t respect the reported value.
Thanks,
Tao
next prev parent reply other threads:[~2023-12-20 12:02 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-18 14:05 [PATCH 0/2] x86: KVM: Limit guest physical bits when 5-level EPT is unsupported Tao Su
2023-12-18 14:05 ` [PATCH 1/2] " Tao Su
2023-12-18 15:13 ` Sean Christopherson
2023-12-19 2:51 ` Chao Gao
2023-12-19 3:40 ` Jim Mattson
2023-12-19 8:09 ` Chao Gao
2023-12-19 15:26 ` Sean Christopherson
2023-12-20 7:16 ` Xiaoyao Li
2023-12-20 15:37 ` Sean Christopherson
2023-12-20 11:59 ` Tao Su [this message]
2023-12-20 13:39 ` Jim Mattson
2023-12-19 8:31 ` Tao Su
2023-12-20 16:28 ` Sean Christopherson
2023-12-21 7:45 ` Tao Su
2023-12-21 8:19 ` Xu Yilun
2024-01-02 23:24 ` Sean Christopherson
2024-01-03 0:34 ` Jim Mattson
2024-01-03 18:04 ` Sean Christopherson
2024-01-04 2:45 ` Chao Gao
2024-01-04 3:40 ` Jim Mattson
2024-01-04 4:34 ` Jim Mattson
2024-01-04 11:56 ` Tao Su
2024-01-04 14:03 ` Jim Mattson
2024-01-04 15:07 ` Chao Gao
2024-01-04 17:02 ` Jim Mattson
2024-01-05 20:26 ` Sean Christopherson
2024-01-08 13:45 ` Tao Su
2024-01-08 15:29 ` Sean Christopherson
2023-12-18 14:05 ` [PATCH 2/2] x86: KVM: Emulate instruction when GPA can't be translated by EPT Tao Su
2023-12-18 15:23 ` Sean Christopherson
2023-12-19 3:10 ` Chao Gao
2023-12-20 13:42 ` Jim Mattson
2024-01-08 13:48 ` Tao Su
2024-01-08 15:19 ` 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=ZYLXKkd6W5L+Drw/@linux.bj.intel.com \
--to=tao1.su@linux.intel.com \
--cc=chao.gao@intel.com \
--cc=chao.p.peng@intel.com \
--cc=eddie.dong@intel.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=xiaoyao.li@intel.com \
--cc=xudong.hao@intel.com \
--cc=yi1.lai@intel.com \
--cc=yuan.yao@linux.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.