From: Sean Christopherson <seanjc@google.com>
To: Amit Shah <Amit.Shah@amd.com>
Cc: "jon@nutanix.com" <jon@nutanix.com>,
"x86@kernel.org" <x86@kernel.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"bp@alien8.de" <bp@alien8.de>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 06/18] KVM: VMX: Wire up Intel MBEC enable/disable logic
Date: Wed, 14 May 2025 05:55:19 -0700 [thread overview]
Message-ID: <aCSSptnxW7EBEzSQ@google.com> (raw)
In-Reply-To: <6dd4eee79fec75a47493251b87c74595826f97bc.camel@amd.com>
On Wed, May 14, 2025, Amit Shah wrote:
> On Tue, 2025-05-13 at 06:28 -0700, Sean Christopherson wrote:
> > On Tue, May 13, 2025, Jon Kohler wrote:
> > > > On May 12, 2025, at 2:23 PM, Sean Christopherson
> > > > This is wrong and unnecessary. As mentioned early, the input that
> > > > matters is vmcs12. This flag should *never* be set for vmcs01.
> > >
> > > I’ll page this back in, but I’m like 75% sure it didn’t work when I
> > > did it that way.
> >
> > Then you had other bugs. The control is per-VMCS and thus needs to
> > be emulated
> > as such. Definitely holler if you get stuck, there's no need to
> > develop this in
> > complete isolation.
>
> Looking at this from the AMD GMET POV, here's how I think support for
> this feature for a Windows guest would be implemented:
>
> * Do not enable the GMET feature in vmcb01. Only the Windows guest (L1
> guest) sets this bit for its own guest (L2 guest). KVM (L0) should see
> the bit set in vmcb02 (and vmcb12). OTOH, pass on the CPUID bit to the
> L1 guest.
>
> * KVM needs to propagate the #NPF to Windows (instead of handling
> anything itself -- ie no shadow page table adjustments or walks
> needed). Windows spawns an L2 guest that causes the #NPF, and Windows
> is the one that needs to consume that fault.
>
> * KVM needs to differentiate an #NPF exit due to GMET or non-GMET
> condition -- check the CPL and U/S bits from the exit, and the NX bit
> from the PTE that faulted. If due to GMET, propagate it to the guest.
> If not, continue handling it
Yes, but no. KVM shouldn't need to do anything special here other than teaching
update_permission_bitmask() to understand the GMET fault case. Ditto for MBEC.
I'd type something up, but I would quickly encounter -ENOCOFFE :-)
With the correct mmu->permissions[], permission_fault() will naturally detect
that a #NPF (or EPT Violation) from L2 due to a GMET/MBEC violation is a fault
in the nNPT/nEPT domain and route the exit to L1.
> (btw KVM MMU API question -- from the #NPF, I have the GPA of the L2
> guest. How to go from that guest GPA to look up the NX bit for that
> page? I skimmed and there doesn't seem to be an existing API for it -
> so is walking the tables the only solution?)
As above, KVM doesn't manually look up individual bits while handling faults.
The walk of the guest page tables (L1's NPT/EPT for this scenario) performed by
FNAME(walk_addr_generic) will gather the effective permissions in walker->pte_access,
and check for a permission_fault() after the walk is completed.
next prev parent reply other threads:[~2025-05-14 12:55 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-13 20:36 [RFC PATCH 00/18] KVM: VMX: Introduce Intel Mode-Based Execute Control (MBEC) Jon Kohler
2025-03-13 20:36 ` [RFC PATCH 01/18] KVM: VMX: Remove EPT_VIOLATIONS_ACC_*_BIT defines Jon Kohler
2025-03-13 20:36 ` [RFC PATCH 02/18] KVM: nVMX: Decouple EPT RWX bits from EPT Violation protection bits Jon Kohler
2025-03-13 20:36 ` [RFC PATCH 03/18] KVM: x86: Add module parameter for Intel MBEC Jon Kohler
2025-05-12 18:08 ` Sean Christopherson
2025-05-13 2:18 ` Jon Kohler
2025-05-13 7:57 ` Shah, Amit
2025-12-23 4:15 ` Jon Kohler
2025-03-13 20:36 ` [RFC PATCH 04/18] KVM: VMX: add cpu_has_vmx_mbec helper Jon Kohler
2025-05-12 18:14 ` Sean Christopherson
2025-05-13 2:17 ` Jon Kohler
2025-03-13 20:36 ` [RFC PATCH 05/18] KVM: x86: Add pt_guest_exec_control to kvm_vcpu_arch Jon Kohler
2025-04-22 6:27 ` Chao Gao
2025-05-12 18:15 ` Sean Christopherson
2025-12-23 4:15 ` Jon Kohler
2025-03-13 20:36 ` [RFC PATCH 06/18] KVM: VMX: Wire up Intel MBEC enable/disable logic Jon Kohler
2025-04-22 7:06 ` Chao Gao
2025-05-12 18:23 ` Sean Christopherson
2025-05-13 2:16 ` Jon Kohler
2025-05-13 13:28 ` Sean Christopherson
2025-05-14 11:14 ` Shah, Amit
2025-05-14 12:55 ` Sean Christopherson [this message]
2025-06-16 9:27 ` Shah, Amit
2025-06-17 14:13 ` Sean Christopherson
2025-07-09 13:40 ` Shah, Amit
2025-12-23 4:15 ` Jon Kohler
2025-03-13 20:36 ` [RFC PATCH 07/18] KVM: VMX: Define VMX_EPT_USER_EXECUTABLE_MASK Jon Kohler
2025-03-13 20:36 ` [RFC PATCH 08/18] KVM: x86/mmu: Remove SPTE_PERM_MASK Jon Kohler
2025-03-13 20:36 ` [RFC PATCH 09/18] KVM: x86/mmu: Extend access bitfield in kvm_mmu_page_role Jon Kohler
2025-05-12 18:32 ` Sean Christopherson
2025-05-13 2:14 ` Jon Kohler
2025-12-23 4:15 ` Jon Kohler
2025-03-13 20:36 ` [RFC PATCH 10/18] KVM: VMX: Extend EPT Violation protection bits Jon Kohler
2025-05-12 18:37 ` Sean Christopherson
2025-12-23 4:15 ` Jon Kohler
2025-03-13 20:36 ` [RFC PATCH 11/18] KVM: VMX: Enhance EPT violation handler for PROT_USER_EXEC Jon Kohler
2025-05-12 18:54 ` Sean Christopherson
2025-12-23 4:15 ` Jon Kohler
2025-03-13 20:36 ` [RFC PATCH 12/18] KVM: x86/mmu: Introduce shadow_ux_mask Jon Kohler
2025-04-23 3:06 ` Chao Gao
2025-05-12 19:13 ` Sean Christopherson
2025-12-23 4:15 ` Jon Kohler
2025-03-13 20:36 ` [RFC PATCH 13/18] KVM: x86/mmu: Adjust SPTE_MMIO_ALLOWED_MASK to understand MBEC Jon Kohler
2025-04-23 5:37 ` Chao Gao
2025-05-12 19:37 ` Sean Christopherson
2025-05-13 2:11 ` Jon Kohler
2025-12-23 4:15 ` Jon Kohler
2025-03-13 20:36 ` [RFC PATCH 14/18] KVM: x86/mmu: Extend is_executable_pte " Jon Kohler
2025-04-23 6:16 ` Chao Gao
2025-05-12 21:16 ` Sean Christopherson
2025-05-13 2:09 ` Jon Kohler
2025-12-23 4:15 ` Jon Kohler
2025-03-13 20:36 ` [RFC PATCH 15/18] KVM: x86/mmu: Extend make_spte " Jon Kohler
2025-05-12 21:29 ` Sean Christopherson
2025-05-13 2:04 ` Jon Kohler
2025-05-13 17:54 ` Sean Christopherson
2025-12-23 4:15 ` Jon Kohler
2025-03-13 20:36 ` [RFC PATCH 16/18] KVM: nVMX: Setup Intel MBEC in nested secondary controls Jon Kohler
2025-05-12 21:32 ` Sean Christopherson
2025-12-23 4:15 ` Jon Kohler
2025-03-13 20:36 ` [RFC PATCH 17/18] KVM: VMX: Allow MBEC with EVMCS Jon Kohler
2025-05-12 21:35 ` Sean Christopherson
2025-05-13 2:01 ` Jon Kohler
2025-12-23 4:16 ` Jon Kohler
2025-03-13 20:36 ` [RFC PATCH 18/18] KVM: x86: Enable module parameter for MBEC Jon Kohler
2025-04-15 9:29 ` [RFC PATCH 00/18] KVM: VMX: Introduce Intel Mode-Based Execute Control (MBEC) Mickaël Salaün
2025-04-15 14:43 ` Sean Christopherson
2025-05-12 15:26 ` Jon Kohler
2025-04-15 14:43 ` Jon Kohler
2025-04-16 15:44 ` Mickaël Salaün
2025-04-23 13:54 ` Adrian-Ken Rueegsegger
2025-05-12 15:26 ` Jon Kohler
2025-05-12 21:46 ` Sean Christopherson
2025-05-13 1:59 ` Jon Kohler
2025-12-23 4:17 ` Jon Kohler
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=aCSSptnxW7EBEzSQ@google.com \
--to=seanjc@google.com \
--cc=Amit.Shah@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jon@nutanix.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=tglx@linutronix.de \
--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 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.