Skip to contentSkip to conversation

FAILED: patch "[PATCH] KVM: x86: Always initialize EFER reserved bits on vendor" failed to apply to 6.12-stable tree

PATCH In review [email protected] 3 participants 3 messages Sep 9 – Sep 11

Subsystems (3)
Stable branch x86 KVM x86
lore
Share & tools
lore

[email protected]

author maintainer
#0 lore raw

The patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y
git checkout FETCH_HEAD
git cherry-pick -x a4b8acd428ba3f03952ef309d7f438dbc357557b
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2026090907-snuff-blot-3cf8@gregkh' --subject-prefix 'PATCH 6.12.y' 'HEAD^..'

Possible dependencies:

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From a4b8acd428ba3f03952ef309d7f438dbc357557b Mon Sep 17 00:00:00 2001
From: Yosry Ahmed <[email protected]>
Date: Mon, 13 Jul 2026 18:10:18 +0000
Subject: [PATCH] KVM: x86: Always initialize EFER reserved bits on vendor
initialization

EFER reserved bits are statically initialized, and do not reset if a vendor module is re-loaded. For example, loading kvm_amd with nested=1 removes EFER.SVME (and potentially EFER.LMSLE) from the reserved bits. Reloading kvm_amd with nested=0 does not add them back, allowing userspace to set EFER.SVME with nested=0.

Re-initializing EFER reserved bits before configuring them on vendor initialization.

Cc [email protected]
Signed-off-by Yosry Ahmed <[email protected]>
Link https://patch.msgid.link/[email protected] open here
Signed-off-by Sean Christopherson <[email protected]>
arch/x86/kvm/msrs.c +8 -2
index 67481429ad6b..a7394bdae029 100644
@@ -19,8 +19,7 @@ bool __read_mostly report_ignored_msrs = true;
 module_param(report_ignored_msrs, bool, 0644);
 EXPORT_SYMBOL_FOR_KVM_INTERNAL(report_ignored_msrs);
 
-/* Enable syscall by default because its emulated by KVM */
-static u64 __read_mostly efer_reserved_bits = ~((u64)EFER_SCE);
+static u64 __read_mostly efer_reserved_bits;
 
 #define MAX_IO_MSRS 256
 

@@ -650,6 +649,13 @@ static int set_efer(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
 	return 0;
 }
 
+void kvm_init_efer_bits(void)
+{
+	/* Enable syscall by default because its emulated by KVM */
+	efer_reserved_bits = ~((u64)EFER_SCE);
+}
+EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_init_efer_bits);
+
 void kvm_enable_efer_bits(u64 mask)
 {
        efer_reserved_bits &= ~mask;
arch/x86/kvm/msrs.h +1 -0
index 9c5c6b33e58f..1f772e171758 100644
@@ -58,6 +58,7 @@ int kvm_get_set_one_reg(struct kvm_vcpu *vcpu, unsigned int ioctl,
 int kvm_get_reg_list(struct kvm_vcpu *vcpu,
 		     struct kvm_reg_list __user *user_list);
 
+void kvm_init_efer_bits(void);
 void kvm_enable_efer_bits(u64);
 bool kvm_valid_efer(struct kvm_vcpu *vcpu, u64 efer);
 int kvm_emulate_msr_read(struct kvm_vcpu *vcpu, u32 index, u64 *data);
arch/x86/kvm/x86.c +2 -0
index 0845551c6cab..cf5fa038ff17 100644
@@ -6910,6 +6910,8 @@ EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_setup_xss_caps);
 
 static void kvm_setup_efer_caps(void)
 {
+	kvm_init_efer_bits();
+
 	if (kvm_cpu_cap_has(X86_FEATURE_LM))
 		kvm_enable_efer_bits(EFER_LME | EFER_LMA);
maintainer
#1 lore raw

PATCH 1/1 KVM: x86: Always initialize EFER reserved bits on vendor initialization

From: Yosry Ahmed <[email protected]>

[ Upstream commit a4b8acd428ba3f03952ef309d7f438dbc357557b ]

EFER reserved bits are statically initialized, and do not reset if a vendor module is re-loaded. For example, loading kvm_amd with nested=1 removes EFER.SVME (and potentially EFER.LMSLE) from the reserved bits. Reloading kvm_amd with nested=0 does not add them back, allowing userspace to set EFER.SVME with nested=0.

Re-initializing EFER reserved bits before configuring them on vendor initialization.

Cc [email protected]
Signed-off-by Yosry Ahmed <[email protected]>
Link https://patch.msgid.link/[email protected] open here
Signed-off-by Sean Christopherson <[email protected]>
[ placed EFER initialization directly in x86.c’s kvm_x86_vendor_init() because this branch lacks kvm_setup_efer_caps() ]
Signed-off-by Sasha Levin <[email protected]>
---
 arch/x86/kvm/x86.c | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)
arch/x86/kvm/x86.c +11 -10
index 9e7c9e3edb5b4..84f8120ac31f8 100644
@@ -108,16 +108,7 @@ EXPORT_SYMBOL_GPL(kvm_host);
 #define emul_to_vcpu(ctxt) \
 	((struct kvm_vcpu *)(ctxt)->vcpu)
 
-/* EFER defaults:
- * - enable syscall per default because its emulated by KVM
- * - enable LME and LMA per default on 64 bit KVM
- */
-#ifdef CONFIG_X86_64
-static
-u64 __read_mostly efer_reserved_bits = ~((u64)(EFER_SCE | EFER_LME | EFER_LMA));
-#else
-static u64 __read_mostly efer_reserved_bits = ~((u64)EFER_SCE);
-#endif
+static u64 __read_mostly efer_reserved_bits;
 
 static u64 __read_mostly cr4_reserved_bits = CR4_RESERVED_BITS;
 

@@ -9818,6 +9809,16 @@ int kvm_x86_vendor_init(struct kvm_x86_init_ops *ops)
 	if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES))
 		rdmsrl(MSR_IA32_ARCH_CAPABILITIES, kvm_host.arch_capabilities);
 
+	/* EFER defaults:
+	 * - enable syscall per default because its emulated by KVM
+	 * - enable LME and LMA per default on 64 bit KVM
+	 */
+#ifdef CONFIG_X86_64
+	efer_reserved_bits = ~((u64)(EFER_SCE | EFER_LME | EFER_LMA));
+#else
+	efer_reserved_bits = ~((u64)EFER_SCE);
+#endif
+
 	r = ops->hardware_setup();
 	if (r != 0)
 		goto out_mmu_exit;
Signature · 1 line
2.53.0
maintainer
#2 lore raw

Re: [PATCH 6.12.y] KVM: x86: Always initialize EFER reserved bits on vendor initialization

Quoted 48 lines · Sasha Levin

From: Yosry Ahmed <[email protected]>

[ Upstream commit a4b8acd428ba3f03952ef309d7f438dbc357557b ]

EFER reserved bits are statically initialized, and do not reset if a vendor module is re-loaded. For example, loading kvm_amd with nested=1 removes EFER.SVME (and potentially EFER.LMSLE) from the reserved bits. Reloading kvm_amd with nested=0 does not add them back, allowing userspace to set EFER.SVME with nested=0.

Re-initializing EFER reserved bits before configuring them on vendor initialization.

Cc [email protected]
Signed-off-by Yosry Ahmed <[email protected]>
Link https://patch.msgid.link/[email protected] open here
Signed-off-by Sean Christopherson <[email protected]>
[ placed EFER initialization directly in x86.c’s kvm_x86_vendor_init() because this branch lacks kvm_setup_efer_caps() ]
Signed-off-by Sasha Levin <[email protected]>
---
 arch/x86/kvm/x86.c | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)
arch/x86/kvm/x86.c +1 -10
index 9e7c9e3edb5b4..84f8120ac31f8 100644
@@ -108,16 +108,7 @@ EXPORT_SYMBOL_GPL(kvm_host);
 #define emul_to_vcpu(ctxt) \
 	((struct kvm_vcpu *)(ctxt)->vcpu)
 
-/* EFER defaults:
- * - enable syscall per default because its emulated by KVM
- * - enable LME and LMA per default on 64 bit KVM
- */
-#ifdef CONFIG_X86_64
-static
-u64 __read_mostly efer_reserved_bits = ~((u64)(EFER_SCE | EFER_LME | EFER_LMA));
-#else
-static u64 __read_mostly efer_reserved_bits = ~((u64)EFER_SCE);
-#endif
+static u64 __read_mostly efer_reserved_bits;
 
 static u64 __read_mostly cr4_reserved_bits = CR4_RESERVED_BITS;
 

@@ -9818,6 +9809,16 @@ int kvm_x86_vendor_init(struct kvm_x86_init_ops *ops)
 	if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES))
 		rdmsrl(MSR_IA32_ARCH_CAPABILITIES, kvm_host.arch_capabilities);

arch/x86/kvm/x86.c int kvm_x86_vendor_init(struct kvm_x86_init_ops *ops) · line 9820

Quoted 10 lines
arch/x86/kvm/x86.c +9 -0
 
+	/* EFER defaults:
+	 * - enable syscall per default because its emulated by KVM
+	 * - enable LME and LMA per default on 64 bit KVM
+	 */
+#ifdef CONFIG_X86_64
+	efer_reserved_bits = ~((u64)(EFER_SCE | EFER_LME | EFER_LMA));
+#else
+	efer_reserved_bits = ~((u64)EFER_SCE);
+#endif

This is going to conflict with "KVM: x86: Disallow EFER.LME and EFER.LMA if long mode is not supported"[*], it probably makes sense to send a version on top of that, both to avoid a conflict when applying and to make it obvious 6.12.y will have the same patch ordering as upstream (though that probably doesn't matter in this case).

[*] https://lore.kernel.org/all/[email protected]

Quoted 7 lines
arch/x86/kvm/x86.c +1 -0
+
 	r = ops->hardware_setup();
 	if (r != 0)
 		goto out_mmu_exit;
Signature · 1 line
2.53.0