GMET (Guest Mode Execute Trap) is an AMD virtualization feature,
essentially the nested paging version of SMEP. Hyper-V uses it;
add it in preparation for making it available to hypervisors
running under KVM.
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/svm.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 123c023fe42c..95469c7d357f 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -382,6 +382,7 @@
#define X86_FEATURE_AVIC (15*32+13) /* "avic" Virtual Interrupt Controller */
#define X86_FEATURE_V_VMSAVE_VMLOAD (15*32+15) /* "v_vmsave_vmload" Virtual VMSAVE VMLOAD */
#define X86_FEATURE_VGIF (15*32+16) /* "vgif" Virtual GIF */
+#define X86_FEATURE_GMET (15*32+17) /* "gmet" Guest Mode Execution Trap */
#define X86_FEATURE_X2AVIC (15*32+18) /* "x2avic" Virtual x2apic */
#define X86_FEATURE_V_SPEC_CTRL (15*32+20) /* "v_spec_ctrl" Virtual SPEC_CTRL */
#define X86_FEATURE_VNMI (15*32+25) /* "vnmi" Virtual NMI */
diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index e2a29e1144a7..47353bef947c 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -239,6 +239,7 @@ struct __attribute__ ((__packed__)) vmcb_control_area {
#define SVM_NESTED_CTL_NP_ENABLE BIT(0)
#define SVM_NESTED_CTL_SEV_ENABLE BIT(1)
#define SVM_NESTED_CTL_SEV_ES_ENABLE BIT(2)
+#define SVM_NESTED_CTL_GMET_ENABLE BIT(3)
#define SVM_TSC_RATIO_RSVD 0xffffff0000000000ULL
--
2.52.0
On Sat, Mar 21, 2026 at 01:09:27AM +0100, Paolo Bonzini wrote:
> GMET (Guest Mode Execute Trap) is an AMD virtualization feature,
> essentially the nested paging version of SMEP. Hyper-V uses it;
> add it in preparation for making it available to hypervisors
> running under KVM.
>
> Cc: Borislav Petkov (AMD) <bp@alien8.de>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> arch/x86/include/asm/cpufeatures.h | 1 +
> arch/x86/include/asm/svm.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index 123c023fe42c..95469c7d357f 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -382,6 +382,7 @@
> #define X86_FEATURE_AVIC (15*32+13) /* "avic" Virtual Interrupt Controller */
> #define X86_FEATURE_V_VMSAVE_VMLOAD (15*32+15) /* "v_vmsave_vmload" Virtual VMSAVE VMLOAD */
> #define X86_FEATURE_VGIF (15*32+16) /* "vgif" Virtual GIF */
> +#define X86_FEATURE_GMET (15*32+17) /* "gmet" Guest Mode Execution Trap */
s!"gmet"!!
With that:
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
> #define X86_FEATURE_X2AVIC (15*32+18) /* "x2avic" Virtual x2apic */
> #define X86_FEATURE_V_SPEC_CTRL (15*32+20) /* "v_spec_ctrl" Virtual SPEC_CTRL */
> #define X86_FEATURE_VNMI (15*32+25) /* "vnmi" Virtual NMI */
> diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
> index e2a29e1144a7..47353bef947c 100644
> --- a/arch/x86/include/asm/svm.h
> +++ b/arch/x86/include/asm/svm.h
> @@ -239,6 +239,7 @@ struct __attribute__ ((__packed__)) vmcb_control_area {
> #define SVM_NESTED_CTL_NP_ENABLE BIT(0)
> #define SVM_NESTED_CTL_SEV_ENABLE BIT(1)
> #define SVM_NESTED_CTL_SEV_ES_ENABLE BIT(2)
> +#define SVM_NESTED_CTL_GMET_ENABLE BIT(3)
>
>
> #define SVM_TSC_RATIO_RSVD 0xffffff0000000000ULL
> --
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Sat, Mar 21, 2026 at 01:09:27AM +0100, Paolo Bonzini wrote:
> GMET (Guest Mode Execute Trap) is an AMD virtualization feature,
> essentially the nested paging version of SMEP. Hyper-V uses it;
> add it in preparation for making it available to hypervisors
> running under KVM.
>
> Cc: Borislav Petkov (AMD) <bp@alien8.de>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> arch/x86/include/asm/cpufeatures.h | 1 +
> arch/x86/include/asm/svm.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index 123c023fe42c..95469c7d357f 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -382,6 +382,7 @@
> #define X86_FEATURE_AVIC (15*32+13) /* "avic" Virtual Interrupt Controller */
> #define X86_FEATURE_V_VMSAVE_VMLOAD (15*32+15) /* "v_vmsave_vmload" Virtual VMSAVE VMLOAD */
> #define X86_FEATURE_VGIF (15*32+16) /* "vgif" Virtual GIF */
> +#define X86_FEATURE_GMET (15*32+17) /* "gmet" Guest Mode Execution Trap */
^^^^^^
Why do you need to show it in /proc/cpuinfo?
> #define X86_FEATURE_X2AVIC (15*32+18) /* "x2avic" Virtual x2apic */
> #define X86_FEATURE_V_SPEC_CTRL (15*32+20) /* "v_spec_ctrl" Virtual SPEC_CTRL */
> #define X86_FEATURE_VNMI (15*32+25) /* "vnmi" Virtual NMI */
> diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
> index e2a29e1144a7..47353bef947c 100644
> --- a/arch/x86/include/asm/svm.h
> +++ b/arch/x86/include/asm/svm.h
> @@ -239,6 +239,7 @@ struct __attribute__ ((__packed__)) vmcb_control_area {
> #define SVM_NESTED_CTL_NP_ENABLE BIT(0)
> #define SVM_NESTED_CTL_SEV_ENABLE BIT(1)
> #define SVM_NESTED_CTL_SEV_ES_ENABLE BIT(2)
> +#define SVM_NESTED_CTL_GMET_ENABLE BIT(3)
>
>
> #define SVM_TSC_RATIO_RSVD 0xffffff0000000000ULL
> --
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Sat, Mar 21, 2026 at 12:58 PM Borislav Petkov <bp@alien8.de> wrote: > > @@ -382,6 +382,7 @@ > > #define X86_FEATURE_AVIC (15*32+13) /* "avic" Virtual Interrupt Controller */ > > #define X86_FEATURE_V_VMSAVE_VMLOAD (15*32+15) /* "v_vmsave_vmload" Virtual VMSAVE VMLOAD */ > > #define X86_FEATURE_VGIF (15*32+16) /* "vgif" Virtual GIF */ > > +#define X86_FEATURE_GMET (15*32+17) /* "gmet" Guest Mode Execution Trap */ > ^^^^^^ > > Why do you need to show it in /proc/cpuinfo? I prefer to be consistent with all the other ones in word 15. Paolo > > #define X86_FEATURE_X2AVIC (15*32+18) /* "x2avic" Virtual x2apic */ > > #define X86_FEATURE_V_SPEC_CTRL (15*32+20) /* "v_spec_ctrl" Virtual SPEC_CTRL */ > > #define X86_FEATURE_VNMI (15*32+25) /* "vnmi" Virtual NMI */
On Sat, Mar 21, 2026 at 02:51:47PM +0100, Paolo Bonzini wrote:
> I prefer to be consistent with all the other ones in word 15.
Sorry, no, /proc/cpuinfo is an ABI.
See Documentation/arch/x86/cpuinfo.rst
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Il sab 21 mar 2026, 16:42 Borislav Petkov <bp@alien8.de> ha scritto: > > On Sat, Mar 21, 2026 at 02:51:47PM +0100, Paolo Bonzini wrote: > > I prefer to be consistent with all the other ones in word 15. > > Sorry, no, /proc/cpuinfo is an ABI. I am not sure what you mean by ABI in this context, maybe "there are rules for whether to add stuff to cpuinfo.rst"? If so, GMET matches what cpuinfo.rst says: * the kernel knows about the feature enough to have an X86_FEATURE bit * the kernel supports it and is currently making it available to userspace * the hardware supports it. The bullet that applies here is the second from the above list: 1) this series makes the feature available for userspace and guests to use it, 2) that requires explicit support, it's not just a bunch of new instructions. I agree that not all word 15 features should be added to /proc/cpuinfo, if that's what you meant by referencing cpuinfo.rst. For example these days something like AVIC would not be added to /proc/cpuinfo because it's transparent to userspace and guests. Paolo
On Mon, Mar 23, 2026 at 08:53:32AM +0100, Paolo Bonzini wrote:
> The bullet that applies here is the second from the above list: 1)
> this series makes the feature available for userspace and guests to
> use it,
Also, if you're going to do this, then this has to be dependent on Kconfig and
be disabled when the kernel support for gmet is not build-enabled.
This explains the issue more:
https://lore.kernel.org/r/cover.1774008873.git.m.wieczorretman@pm.me
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Mon, Mar 23, 2026 at 08:53:32AM +0100, Paolo Bonzini wrote:
> I am not sure what you mean by ABI in this context, maybe "there are
It means that once we show it in /proc/cpuinfo, we're stuck with it forever
because something in userspace might depend on it.
So we try to avoid that if it can be solved in a different way.
> rules for whether to add stuff to cpuinfo.rst"? If so, GMET matches
> what cpuinfo.rst says:
>
> * the kernel knows about the feature enough to have an X86_FEATURE bit
> * the kernel supports it and is currently making it available to userspace
> * the hardware supports it.
>
> The bullet that applies here is the second from the above list: 1)
> this series makes the feature available for userspace and guests to
> use it,
This is the key question: what in userspace is going to parse /proc/cpuinfo
and look for "gmet"?
Because parsing /proc/cpuinfo is the silliest option available but glibc does
it and for some things like, "did the kernel *actually* enable this?" it is
the only way.
If the above applies, can this be solved in a different way? CPUID,
guest_cpu_cap_has(), whatever...
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Mon, Mar 23, 2026 at 1:17 PM Borislav Petkov <bp@alien8.de> wrote: > This is the key question: what in userspace is going to parse /proc/cpuinfo > and look for "gmet"? To be honest probably not. They can open /dev/kvm and call KVM_GET_SUPPORTED_CPUID to get the same information. The difference is that /proc/cpuinfo will always have gmet even if the module parameter is zero, while /dev/kvm won't. Based on your other message, it seems like you want this to be a bug rather than a feature, so let's shelve this, can you ack it with "" instead? Paolo
On Mon, Mar 23, 2026 at 01:22:10PM +0100, Paolo Bonzini wrote:
> On Mon, Mar 23, 2026 at 1:17 PM Borislav Petkov <bp@alien8.de> wrote:
> > This is the key question: what in userspace is going to parse /proc/cpuinfo
> > and look for "gmet"?
>
> To be honest probably not. They can open /dev/kvm and call
> KVM_GET_SUPPORTED_CPUID to get the same information.
>
> The difference is that /proc/cpuinfo will always have gmet even if the
> module parameter is zero, while /dev/kvm won't. Based on your other
> message, it seems like you want this to be a bug rather than a
> feature, so let's shelve this, can you ack it with "" instead?
Right, you don't need to add any "" anymore - just a normal comment and that's
it. Lemme reply to the patch.
And *if* we ever decide that we need to show it to userspace, we can always do
that later but then we'll actually have a proper justification for doing so.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
© 2016 - 2026 Red Hat, Inc.