AI Trajectory

Trajectory: (Expand/Collapse All)
Seq	Timestamp	Type	Name	Duration
0/0	2026/09/30 23:39	flow	patch-triage	2m Args: null Results: { "EnableConfigs": [ "KVM", "KVM_INTEL", "KVM_AMD" ], "FocusSymbols": [ "kvm_valid_efer", "__kvm_valid_efer", "cpuid_func_emulated", "kvm_vcpu_after_set_cpuid", "set_efer", "efer_trap" ], "KMSANReasoning": "The patch series updates KVM's handling of the AMD EFER_LMSLE_MBZ (EFER Long Mode Segment Limit Enable Must Be Zero) feature bit across CPUID emulation and MSR validity checking (in cpuid.c, msrs.c, svm.c, vmx.c, and x86.c).\n\nReviewing the changes for KMSAN applicability:\n1. No uninitialized memory usage: All modifications deal with CPU capability bitmasks and MSR validity validation logic.\n2. In `cpuid_func_emulated()`, the modified `struct kvm_cpuid_entry2 entry` is fully zero-initialized at the start of the function via `memset(entry, 0, sizeof(entry))`. Furthermore, for func 0x80000008, it returns 0 when called from `KVM_GET_EMULATED_CPUID` (`include_partially_emulated` is false).\n3. The only other structure touched is `struct msr_data msr_info` in `efer_trap()`, which already had all its fields explicitly initialized, and the patch merely adjusts bitwise masking on `msr_info.data`.\n4. No heap or stack buffers are allocated, no struct paddings or uninitialized fields are exposed to userspace or the guest, and no buffer bounds or length checks are altered.\n\nTherefore, this patch does not introduce any risks related to uninitialized memory reads or kernel info-leaks, and running a dedicated KMSAN fuzzing session is not warranted.", "NeedsKMSAN": false, "Reasoning": "The patch updates KVM's handling of the long mode segment limit defeature bit (EFER_LMSLE_MBZ, CPUID 0x80000008:EBX[20]). It modifies emulated CPUID generation, guest CPUID capability configuration, EFER validation logic across MSR writes and SREGS, and SEV-ES EFER trap handling in SVM. These code paths are actively reachable through /dev/kvm ioctls (such as KVM_SET_CPUID2, KVM_GET_EMULATED_CPUID, KVM_SET_SREGS, and guest MSR accesses) in standard QEMU/virtualized environments on amd64.", "WorthFuzzing": true }
1/1	2026/09/30 23:39	action	read-patch-diff	0m Args: null Results: { "PatchDiff": "commit 353a3b48533194453b931df2871f76818229ba98\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Wed Sep 30 23:39:41 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst\nindex e0430cc750c9e..2852bf94828be 100644\n--- a/Documentation/virt/kvm/api.rst\n+++ b/Documentation/virt/kvm/api.rst\n@@ -9635,6 +9635,31 @@ On older versions of Linux, CPU[EAX=1]:ECX[24] (TSC_DEADLINE) is not reported by\n is present and the kernel has enabled in-kernel emulation of the local APIC.\n On newer versions, ``KVM_GET_SUPPORTED_CPUID`` does report the bit as available.\n \n+Long mode segment limits\n+~~~~~~~~~~~~~~~~~~~~~~~~\n+\n+CPU[EAX=0x80000008]:EBX[20] (EFER_LMSLE_MBZ) is a \"defeature\" bit: it is set\n+when the CPU does not support long mode segment limits, and so requires\n+EFER.LMSLE to be zero. KVM reports the bit via ``KVM_GET_SUPPORTED_CPUID`` if\n+and only if KVM refuses to set EFER.LMSLE, i.e. if the CPU doesn't support long\n+mode segment limits, or if nested SVM is unsupported. KVM therefore reports\n+the bit on all Intel hosts, as KVM allows EFER.LMSLE only when nested SVM is\n+enabled.\n+\n+KVM never reports the bit via ``KVM_GET_EMULATED_CPUID``, but userspace may set\n+it via ``KVM_SET_CPUID2`` even on a host where KVM doesn't report it. KVM\n+honors the guest's enumeration and rejects EFER.LMSLE=1 accordingly. That lets\n+userspace defeature a vCPU on a host that does support long mode segment\n+limits, so that the vCPU can later be migrated to a host that doesn't, e.g. so\n+that a vCPU created on AMD Rome can be migrated to Milan and later, which\n+dropped support for long mode segment limits. The opposite direction needs no\n+emulation, as a host that lacks long mode segment limits already enumerates the\n+defeature.\n+\n+Note, ``KVM_SET_MSRS`` is exempt from the check, as host-initiated MSR writes\n+skip guest CPUID checks so that userspace can set MSRs before it sets guest\n+CPUID. ``KVM_SET_SREGS`` and nested VMRUN are not exempt.\n+\n CPU topology\n ~~~~~~~~~~~~\n \ndiff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c\nindex 851f151efb35b..53d205eda3359 100644\n--- a/arch/x86/kvm/cpuid.c\n+++ b/arch/x86/kvm/cpuid.c\n@@ -1171,6 +1171,10 @@ void kvm_initialize_cpu_caps(void)\n \t\tF(AMD_STIBP),\n \t\tF(AMD_STIBP_ALWAYS_ON),\n \t\tF(AMD_IBRS_SAME_MODE),\n+\t\t/\n+\t\t Vendor code also sets EFER_LMSLE_MBZ if KVM itself\n+\t\t * can't support EFER.LMSLE, e.g. if nested SVM is disabled.\n+\t\t /\n \t\tPASSTHROUGH_F(EFER_LMSLE_MBZ),\n \t\tF(AMD_PSFD),\n \t\tF(AMD_IBPB_RET),\n@@ -1415,6 +1419,22 @@ static int cpuid_func_emulated(struct kvm_cpuid_entry2 entry, u32 func, u32 ind\n \t\tif (kvm_cpu_cap_has(X86_FEATURE_RDTSCP))\n \t\t\tentry-\u003eecx = feature_bit(RDPID);\n \t\treturn 1;\n+\tcase 0x80000008:\n+\t\t/\n+\t\t Honor the guest's EFER_LMSLE_MBZ even if the underlying CPU\n+\t\t * allows setting EFER.LMSLE, e.g. to allow migrating a vCPU\n+\t\t * between hosts with and without EFER.LMSLE support. To avoid\n+\t\t * breaking existing setups that reflect KVM's supported CPUID\n+\t\t * into the guest, KVM doesn't advertise EFER_LMSLE_MBZ unless\n+\t\t * KVM can't support EFER.LMSLE=1.\n+\t\t /\n+\t\tif (include_partially_emulated \u0026\u0026\n+\t\t !kvm_cpu_cap_has(X86_FEATURE_EFER_LMSLE_MBZ)) {\n+\t\t\tentry-\u003eebx \|= feature_bit(EFER_LMSLE_MBZ);\n+\t\t\treturn 1;\n+\t\t}\n+\t\t/ Nothing in 0x80000008 is fully emulated, don't emit an entry. /\n+\t\treturn 0;\n \tdefault:\n \t\treturn 0;\n \t}\ndiff --git a/arch/x86/kvm/msrs.c b/arch/x86/kvm/msrs.c\nindex dd3bb04878ca6..b519fb90776e2 100644\n--- a/arch/x86/kvm/msrs.c\n+++ b/arch/x86/kvm/msrs.c\n@@ -598,9 +598,19 @@ static bool __kvm_valid_efer(struct kvm_vcpu vcpu, u64 efer)\n \tif (efer \u0026 EFER_NX \u0026\u0026 !guest_cpu_cap_has(vcpu, X86_FEATURE_NX))\n \t\treturn false;\n \n-\treturn true;\n+\t/\n+\t EFER_LMSLE_MBZ is a \"defeature\" bit, i.e. is set when the CPU does\n+\t * not support long mode segment limits, and so is the only EFER\n+\t * check whose polarity is inverted: EFER.LMSLE is legal if and only if\n+\t * the guest does not have the defeature.\n+\t /\n+\tif (efer \u0026 EFER_LMSLE \u0026\u0026\n+\t guest_cpu_cap_has(vcpu, X86_FEATURE_EFER_LMSLE_MBZ))\n+\t\treturn false;\n \n+\treturn true;\n }\n+\n bool kvm_valid_efer(struct kvm_vcpu vcpu, u64 efer)\n {\n \tif (efer \u0026 ~kvm_caps.supported_efer_bits)\ndiff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c\nindex 7d59d301e1e54..90a80aad672f6 100644\n--- a/arch/x86/kvm/svm/svm.c\n+++ b/arch/x86/kvm/svm/svm.c\n@@ -2759,10 +2759,19 @@ static int efer_trap(struct kvm_vcpu vcpu)\n \t bit in svm_set_efer(), but __kvm_valid_efer() checks it against\n \t * whether the guest has X86_FEATURE_SVM - this avoids a failure if\n \t * the guest doesn't have X86_FEATURE_SVM.\n+\t \n+\t Clear EFER_LMSLE for a related reason: EFER writes are trapped,\n+\t * not intercepted, i.e. hardware has already committed the write by\n+\t * the time KVM gains control, and the trap is enabled if and only if\n+\t * the guest is SEV-ES, whose EFER lives in the encrypted VMSA and so\n+\t * can't be fixed up by KVM. Rejecting EFER.LMSLE=1 would inject a #GP\n+\t * and leave EFER.LMSLE set in the guest, which is strictly worse\n+\t * than honoring a write that hardware itself allowed.\n \t /\n \tmsr_info.host_initiated = false;\n \tmsr_info.index = MSR_EFER;\n-\tmsr_info.data = to_svm(vcpu)-\u003evmcb-\u003econtrol.exit_info_1 \u0026 ~EFER_SVME;\n+\tmsr_info.data = to_svm(vcpu)-\u003evmcb-\u003econtrol.exit_info_1 \u0026\n+\t\t\t~(EFER_SVME \| EFER_LMSLE);\n \tret = kvm_set_msr_common(vcpu, \u0026msr_info);\n \n \treturn kvm_complete_insn_gp(vcpu, ret);\n@@ -5571,6 +5580,16 @@ static __init void svm_set_cpu_caps(void)\n \t boot_cpu_has(X86_FEATURE_AMD_SSBD))\n \t\tkvm_cpu_cap_set(X86_FEATURE_VIRT_SSBD);\n \n+\t/\n+\t * Tell userspace that EFER.LMSLE must be zero if nested SVM is\n+\t * disabled, as KVM allows EFER.LMSLE if and only if nested SVM is\n+\t * supported (a historical artifact of commit eec4b140c924 (\"KVM: SVM:\n+\t * Allow EFER.LMSLE to be set with nested svm\"), not an architectural\n+\t * requirement).\n+\t /\n+\tif (!nested)\n+\t\tkvm_cpu_cap_set(X86_FEATURE_EFER_LMSLE_MBZ);\n+\n \tif (enable_pmu) {\n \t\t/\n \t\t * Enumerate support for PERFCTR_CORE if and only if KVM has\ndiff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c\nindex 612ab07d4100f..f144c1e1c63f2 100644\n--- a/arch/x86/kvm/vmx/vmx.c\n+++ b/arch/x86/kvm/vmx/vmx.c\n@@ -8137,6 +8137,13 @@ static __init void vmx_set_cpu_caps(void)\n \t\tkvm_cpu_cap_clear(X86_FEATURE_IBT);\n \t}\n \n+\t/\n+\t CPUID 0x80000008. Tell userspace that EFER.LMSLE must be zero; KVM\n+\t * never allows EFER.LMSLE to be set on Intel CPUs, as KVM supports long\n+\t * mode segment limits only in conjunction with nested SVM.\n+\t /\n+\tkvm_cpu_cap_set(X86_FEATURE_EFER_LMSLE_MBZ);\n+\n \tkvm_setup_xss_caps();\n \tkvm_finalize_cpu_caps();\n }\ndiff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c\nindex 79468ddfe4736..830cb9320d892 100644\n--- a/arch/x86/kvm/x86.c\n+++ b/arch/x86/kvm/x86.c\n@@ -6930,7 +6930,14 @@ static void kvm_setup_efer_caps(void)\n \n \tif (kvm_cpu_cap_has(X86_FEATURE_SVM)) {\n \t\tkvm_caps.supported_efer_bits \|= EFER_SVME;\n-\t\tif (!boot_cpu_has(X86_FEATURE_EFER_LMSLE_MBZ))\n+\n+\t\t/\n+\t\t * Enumerating EFER_LMSLE_MBZ and allowing EFER.LMSLE=1\n+\t\t * would be nonsensical. Note, vendor code sets the defeature\n+\t\t * if KVM can't support EFER.LMSLE for any reason, i.e. this\n+\t\t * needs to consult KVM's capabilities, not just raw CPUID.\n+\t\t /\n+\t\tif (!kvm_cpu_cap_has(X86_FEATURE_EFER_LMSLE_MBZ))\n \t\t\tkvm_caps.supported_efer_bits \|= EFER_LMSLE;\n \t}\n }\ndiff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm\nindex 96bab7002d39e..2554464d8b96f 100644\n--- a/tools/testing/selftests/kvm/Makefile.kvm\n+++ b/tools/testing/selftests/kvm/Makefile.kvm\n@@ -117,7 +117,7 @@ TEST_GEN_PROGS_x86 += x86/state_test\n TEST_GEN_PROGS_x86 += x86/vmx_preemption_timer_test\n TEST_GEN_PROGS_x86 += x86/svm_vmcall_test\n TEST_GEN_PROGS_x86 += x86/svm_int_ctl_test\n-TEST_GEN_PROGS_x86 += x86/svm_nested_clear_efer_svme\n+TEST_GEN_PROGS_x86 += x86/svm_nested_efer_test\n TEST_GEN_PROGS_x86 += x86/svm_nested_shutdown_test\n TEST_GEN_PROGS_x86 += x86/svm_nested_soft_inject_test\n TEST_GEN_PROGS_x86 += x86/svm_nested_vmcb12_gpa\ndiff --git a/tools/testing/selftests/kvm/include/x86/processor.h b/tools/testing/selftests/kvm/include/x86/processor.h\nindex 6e6f70035508a..5bc1bc110a347 100644\n--- a/tools/testing/selftests/kvm/include/x86/processor.h\n+++ b/tools/testing/selftests/kvm/include/x86/processor.h\n@@ -216,6 +216,7 @@ struct kvm_x86_cpu_feature {\n #define\tX86_FEATURE_INVTSC\t\tKVM_X86_CPU_FEATURE(0x80000007, 0, EDX, 8)\n #define\tX86_FEATURE_RDPRU\t\tKVM_X86_CPU_FEATURE(0x80000008, 0, EBX, 4)\n #define\tX86_FEATURE_AMD_IBPB\t\tKVM_X86_CPU_FEATURE(0x80000008, 0, EBX, 12)\n+#define\tX86_FEATURE_EFER_LMSLE_MBZ\tKVM_X86_CPU_FEATURE(0x80000008, 0, EBX, 20)\n #define\tX86_FEATURE_NPT\t\t\tKVM_X86_CPU_FEATURE(0x8000000A, 0, EDX, 0)\n #define\tX86_FEATURE_LBRV\t\tKVM_X86_CPU_FEATURE(0x8000000A, 0, EDX, 1)\n #define\tX86_FEATURE_NRIPS\t\tKVM_X86_CPU_FEATURE(0x8000000A, 0, EDX, 3)\n@@ -1429,6 +1430,14 @@ static inline bool get_kvm_amd_param_bool(const char param)\n \treturn kvm_get_module_param_bool(\"kvm_amd\", param);\n }\n \n+static inline int get_common_kvm_vendor_param_bool(const char param)\n+{\n+\tif (host_cpu_is_intel)\n+\t\treturn get_kvm_intel_param_bool(param);\n+\n+\treturn get_kvm_amd_param_bool(param);\n+}\n+\n static inline int get_kvm_intel_param_integer(const char param)\n {\n \treturn kvm_get_module_param_integer(\"kvm_intel\", param);\n@@ -1439,6 +1448,14 @@ static inline int get_kvm_amd_param_integer(const char param)\n \treturn kvm_get_module_param_integer(\"kvm_amd\", param);\n }\n \n+static inline int get_common_kvm_vendor_param_integer(const char param)\n+{\n+\tif (host_cpu_is_intel)\n+\t\treturn get_kvm_intel_param_integer(param);\n+\n+\treturn get_kvm_amd_param_integer(param);\n+}\n+\n static inline bool kvm_is_pmu_enabled(void)\n {\n \treturn get_kvm_param_bool(\"enable_pmu\");\n@@ -1446,10 +1463,7 @@ static inline bool kvm_is_pmu_enabled(void)\n \n static inline bool kvm_is_mediated_pmu_enabled(void)\n {\n-\tif (host_cpu_is_intel)\n-\t\treturn get_kvm_intel_param_bool(\"enable_mediated_pmu\");\n-\n-\treturn get_kvm_amd_param_bool(\"enable_mediated_pmu\");\n+\treturn get_common_kvm_vendor_param_bool(\"enable_mediated_pmu\");\n }\n \n static inline bool kvm_is_forced_emulation_enabled(void)\n@@ -1472,6 +1486,16 @@ static inline bool kvm_is_lbrv_enabled(void)\n \treturn !!get_kvm_amd_param_integer(\"lbrv\");\n }\n \n+/\n+ Do NOT use this to check for nVMX or nSVM support. Querying kvm_cpu_has()\n+ * for either of X86_FEATURE_{VMX,SVM} is the idiomatic way to check for nested\n+ * virtualization support. Use this only to validate KVM's own enumeration.\n+ /\n+static inline bool kvm_is_nested_virtualization_enabled(void)\n+{\n+\treturn get_common_kvm_vendor_param_integer(\"nested\");\n+}\n+\n u64 vm_get_pte(struct kvm_vm vm, gva_t gva);\n \n u64 kvm_hypercall(u64 nr, u64 a0, u64 a1, u64 a2, u64 a3);\ndiff --git a/tools/testing/selftests/kvm/x86/svm_nested_clear_efer_svme.c b/tools/testing/selftests/kvm/x86/svm_nested_clear_efer_svme.c\ndeleted file mode 100644\nindex 6bc301207cbcb..0000000000000\n--- a/tools/testing/selftests/kvm/x86/svm_nested_clear_efer_svme.c\n+++ /dev/null\n@@ -1,50 +0,0 @@\n-// SPDX-License-Identifier: GPL-2.0-only\n-/\n- * Copyright (C) 2026, Google LLC.\n- /\n-#include \"kvm_util.h\"\n-#include \"vmx.h\"\n-#include \"svm_util.h\"\n-#include \"kselftest.h\"\n-\n-\n-static void l2_guest_code(void)\n-{\n-\tunsigned long efer = rdmsr(MSR_EFER);\n-\n-\t/ generic_svm_setup() initializes EFER_SVME set for L2 /\n-\tGUEST_ASSERT(efer \u0026 EFER_SVME);\n-\twrmsr(MSR_EFER, efer \u0026 ~EFER_SVME);\n-\n-\t/ Unreachable, L1 should be shutdown /\n-\tGUEST_ASSERT(0);\n-}\n-\n-static void l1_guest_code(struct svm_test_data svm)\n-{\n-\tgeneric_svm_setup(svm, l2_guest_code);\n-\trun_guest(svm-\u003evmcb, svm-\u003evmcb_gpa);\n-\n-\t/* Unreachable, L1 should be shutdown /\n-\tGUEST_ASSERT(0);\n-}\n-\n-int main(int argc, char argv[])\n-{\n-\tstruct kvm_vcpu vcpu;\n-\tstruct kvm_vm vm;\n-\tgva_t nested_gva = 0;\n-\n-\tTEST_REQUIRE(kvm_cpu_has(X86_FEATURE_SVM));\n-\n-\tvm = vm_create_with_one_vcpu(\u0026vcpu, l1_guest_code);\n-\n-\tvcpu_alloc_svm(vm, \u0026nested_gva);\n-\tvcpu_args_set(vcpu, 1, nested_gva);\n-\n-\tvcpu_run(vcpu);\n-\tTEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_SHUTDOWN);\n-\n-\tkvm_vm_free(vm);\n-\treturn 0;\n-}\ndiff --git a/tools/testing/selftests/kvm/x86/svm_nested_efer_test.c b/tools/testing/selftests/kvm/x86/svm_nested_efer_test.c\nnew file mode 100644\nindex 0000000000000..fa0d76a9c390b\n--- /dev/null\n+++ b/tools/testing/selftests/kvm/x86/svm_nested_efer_test.c\n@@ -0,0 +1,266 @@\n+// SPDX-License-Identifier: GPL-2.0-only\n+/\n+ Tests for KVM's handling of EFER bits whose behavior is tied to nested SVM.\n+ \n+ Copyright (C) 2026, Google LLC.\n+ /\n+#include \"test_util.h\"\n+#include \"kvm_util.h\"\n+#include \"processor.h\"\n+#include \"svm_util.h\"\n+#include \"kselftest.h\"\n+\n+static bool l2_ran;\n+\n+static void l2_clear_efer_svme(void)\n+{\n+\tu64 efer = rdmsr(MSR_EFER);\n+\n+\t/ generic_svm_setup() initializes EFER_SVME set for L2 /\n+\tGUEST_ASSERT(efer \u0026 EFER_SVME);\n+\twrmsr(MSR_EFER, efer \u0026 ~EFER_SVME);\n+\n+\t/ Unreachable, L1 should be shutdown /\n+\tGUEST_ASSERT(0);\n+}\n+\n+static void l1_clear_efer_svme(struct svm_test_data svm)\n+{\n+\tgeneric_svm_setup(svm, l2_clear_efer_svme);\n+\trun_guest(svm-\u003evmcb, svm-\u003evmcb_gpa);\n+\n+\t/* Unreachable, L1 should be shutdown /\n+\tGUEST_ASSERT(0);\n+}\n+\n+static void l2_lmsle(void)\n+{\n+\tGUEST_ASSERT(rdmsr(MSR_EFER) \u0026 EFER_LMSLE);\n+\tl2_ran = true;\n+\tvmmcall();\n+}\n+\n+static void l1_lmsle(struct svm_test_data svm)\n+{\n+\tbool lmsle_mbz = this_cpu_has(X86_FEATURE_EFER_LMSLE_MBZ);\n+\tstruct vmcb vmcb = svm-\u003evmcb;\n+\tu64 efer = rdmsr(MSR_EFER);\n+\n+\t/\n+\t * Selftests' vCPUs are created with EFER.LMSLE clear; the sub-tests\n+\t * below need to start from a clean slate.\n+\t /\n+\tGUEST_ASSERT(!(efer \u0026 EFER_LMSLE));\n+\tGUEST_ASSERT(!l2_ran);\n+\n+\t/\n+\t * Per the APM, if EFER_LMSLE_MBZ is enumerated in CPUID, \"64-bit mode\n+\t * segment limit checking is not supported and attempting to set\n+\t * EFER.LMSLE = 1 causes a #GP exception\".\n+\t /\n+\tif (lmsle_mbz) {\n+\t\tGUEST_ASSERT_EQ(wrmsr_safe(MSR_EFER, efer \| EFER_LMSLE), GP_VECTOR);\n+\t\tGUEST_ASSERT(!(rdmsr(MSR_EFER) \u0026 EFER_LMSLE));\n+\t} else {\n+\t\tGUEST_ASSERT_EQ(wrmsr_safe(MSR_EFER, efer \| EFER_LMSLE), 0);\n+\t\tGUEST_ASSERT(rdmsr(MSR_EFER) \u0026 EFER_LMSLE);\n+\n+\t\t/\n+\t\t * Restore EFER so that generic_svm_setup() doesn't propagate\n+\t\t * EFER.LMSLE into vmcb12 on its own, i.e. so that the VMRUN\n+\t\t * sub-test actually tests what it thinks it's testing.\n+\t\t /\n+\t\twrmsr(MSR_EFER, efer);\n+\t}\n+\n+\t/\n+\t * VMRUN's consistency checks reject \"any MBZ bit of EFER\", i.e. a\n+\t * vmcb12 with EFER.LMSLE set must generate VMEXIT_INVALID when the\n+\t * defeature is enumerated.\n+\t /\n+\tgeneric_svm_setup(svm, l2_lmsle);\n+\tvmcb-\u003esave.efer \|= EFER_LMSLE;\n+\trun_guest(vmcb, svm-\u003evmcb_gpa);\n+\n+\tif (lmsle_mbz) {\n+\t\tGUEST_ASSERT_EQ(vmcb-\u003econtrol.exit_code, SVM_EXIT_ERR);\n+\t\tGUEST_ASSERT(!l2_ran);\n+\t} else {\n+\t\tGUEST_ASSERT_EQ(vmcb-\u003econtrol.exit_code, SVM_EXIT_VMMCALL);\n+\t\tGUEST_ASSERT(l2_ran);\n+\t\tGUEST_ASSERT(vmcb-\u003esave.efer \u0026 EFER_LMSLE);\n+\t}\n+\n+\tGUEST_DONE();\n+}\n+\n+static struct kvm_vcpu create_l1_vcpu(struct kvm_vm *vm, void l1_guest_code)\n+{\n+\tstruct kvm_vcpu vcpu;\n+\tgva_t svm_gva;\n+\n+\tvm = vm_create_with_one_vcpu(\u0026vcpu, l1_guest_code);\n+\n+\tvcpu_alloc_svm(vm, \u0026svm_gva);\n+\tvcpu_args_set(vcpu, 1, svm_gva);\n+\n+\treturn vcpu;\n+}\n+\n+static void test_enumeration(void)\n+{\n+\tbool lmsle_mbz;\n+\n+\t/\n+\t * EFER_LMSLE_MBZ, CPUID.80000008H:EBX[bit 20], is a \"defeature\" bit,\n+\t * i.e. is set when the CPU does not support long mode segment\n+\t * limits. KVM enumerates the defeature if and only if KVM refuses to\n+\t * set EFER.LMSLE, i.e. if the CPU doesn't support LMSLE, or if KVM\n+\t * doesn't support nested SVM. Derive the expectation from raw CPUID\n+\t * and kvm_amd's \"nested\" module param rather than from\n+\t * kvm_cpu_has(X86_FEATURE_SVM), so that the assertion doesn't simply\n+\t * compare KVM's enumeration to itself.\n+\t /\n+\tlmsle_mbz = this_cpu_has(X86_FEATURE_EFER_LMSLE_MBZ) \|\|\n+\t\t !this_cpu_has(X86_FEATURE_SVM) \|\|\n+\t\t !kvm_is_nested_virtualization_enabled();\n+\n+\tTEST_ASSERT_EQ(kvm_cpu_has(X86_FEATURE_EFER_LMSLE_MBZ), lmsle_mbz);\n+\n+\tksft_test_result_pass(\"KVM enumerates EFER_LMSLE_MBZ=%d\\n\", lmsle_mbz);\n+}\n+\n+static void test_clear_efer_svme(void)\n+{\n+\tstruct kvm_vcpu vcpu;\n+\tstruct kvm_vm vm;\n+\n+\tvcpu = create_l1_vcpu(\u0026vm, l1_clear_efer_svme);\n+\n+\tvcpu_run(vcpu);\n+\tTEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_SHUTDOWN);\n+\n+\tkvm_vm_free(vm);\n+\tksft_test_result_pass(\"L2 clearing EFER.SVME shuts down L1\\n\");\n+}\n+\n+static void test_lmsle(bool lmsle_mbz)\n+{\n+\tstruct kvm_vcpu vcpu;\n+\tstruct kvm_vm vm;\n+\tstruct ucall uc;\n+\n+\tvcpu = create_l1_vcpu(\u0026vm, l1_lmsle);\n+\n+\tvcpu_set_or_clear_cpuid_feature(vcpu, X86_FEATURE_EFER_LMSLE_MBZ,\n+\t\t\t\t\tlmsle_mbz);\n+\n+\tvcpu_run(vcpu);\n+\tTEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_IO);\n+\n+\tswitch (get_ucall(vcpu, \u0026uc)) {\n+\tcase UCALL_ABORT:\n+\t\tREPORT_GUEST_ASSERT(uc);\n+\tcase UCALL_DONE:\n+\t\tbreak;\n+\tdefault:\n+\t\tTEST_FAIL(\"Unexpected ucall: %lu\", uc.cmd);\n+\t}\n+\n+\tkvm_vm_free(vm);\n+\tksft_test_result_pass(\"Guest EFER_LMSLE_MBZ=%d\\n\", lmsle_mbz);\n+}\n+\n+static void test_host_initiated_lmsle(void)\n+{\n+\tstruct kvm_vcpu vcpu;\n+\tstruct kvm_vm vm;\n+\tu64 efer;\n+\n+\tvm = vm_create_with_one_vcpu(\u0026vcpu, NULL);\n+\tvcpu_set_cpuid_feature(vcpu, X86_FEATURE_EFER_LMSLE_MBZ);\n+\n+\t/\n+\t * EFER_LMSLE_MBZ is a guest CPUID consistency check, not a host\n+\t * capability, i.e. must not be enforced against host-initiated writes,\n+\t * so that userspace can set MSRs before it sets guest CPUID.\n+\t /\n+\tefer = vcpu_get_msr(vcpu, MSR_EFER);\n+\tTEST_ASSERT(!(efer \u0026 EFER_LMSLE), \"EFER.LMSLE unexpectedly set\");\n+\n+\tvcpu_set_msr(vcpu, MSR_EFER, efer \| EFER_LMSLE);\n+\tTEST_ASSERT_EQ(vcpu_get_msr(vcpu, MSR_EFER), efer \| EFER_LMSLE);\n+\n+\tkvm_vm_free(vm);\n+\tksft_test_result_pass(\"Host-initiated EFER.LMSLE=1 is allowed\\n\");\n+}\n+\n+static void test_sregs_lmsle(void)\n+{\n+\tstruct kvm_vcpu vcpu;\n+\tstruct kvm_sregs sregs;\n+\tstruct kvm_vm vm;\n+\tint rc;\n+\n+\tvm = vm_create_with_one_vcpu(\u0026vcpu, NULL);\n+\tvcpu_set_cpuid_feature(vcpu, X86_FEATURE_EFER_LMSLE_MBZ);\n+\n+\t/\n+\t * Unlike KVM_SET_MSRS, KVM_SET_SREGS runs the full set of guest CPUID\n+\t * checks, i.e. rejects EFER.LMSLE even though it's host-initiated.\n+\t /\n+\tvcpu_sregs_get(vcpu, \u0026sregs);\n+\tTEST_ASSERT(!(sregs.efer \u0026 EFER_LMSLE), \"EFER.LMSLE unexpectedly set\");\n+\n+\tsregs.efer \|= EFER_LMSLE;\n+\trc = _vcpu_sregs_set(vcpu, \u0026sregs);\n+\tTEST_ASSERT(rc, \"KVM allowed EFER.LMSLE with EFER_LMSLE_MBZ set\");\n+\n+\tkvm_vm_free(vm);\n+\tksft_test_result_pass(\"KVM_SET_SREGS rejects EFER.LMSLE=1\\n\");\n+}\n+\n+int main(int argc, char argv[])\n+{\n+\tbool has_nested_svm, has_lmsle;\n+\n+\tksft_print_header();\n+\tksft_set_plan(6);\n+\n+\ttest_enumeration();\n+\n+\t/\n+\t The sub-tests below need to actually run a nested guest, and the\n+\t * EFER.LMSLE sub-tests additionally need KVM to allow EFER.LMSLE.\n+\t * It's KVM's view of the world, not raw CPUID, that dictates whether\n+\t * EFER.LMSLE is allowed, i.e. whether the defeature is emulated.\n+\t */\n+\thas_nested_svm = kvm_cpu_has(X86_FEATURE_SVM);\n+\thas_lmsle = has_nested_svm \u0026\u0026\n+\t\t !kvm_cpu_has(X86_FEATURE_EFER_LMSLE_MBZ);\n+\n+\tif (!has_nested_svm)\n+\t\tksft_print_msg(\"Nested SVM unsupported\\n\");\n+\telse if (!has_lmsle)\n+\t\tksft_print_msg(\"KVM doesn't support EFER.LMSLE\\n\");\n+\n+\tif (has_nested_svm) {\n+\t\ttest_clear_efer_svme();\n+\t\ttest_lmsle(true);\n+\t} else {\n+\t\tksft_test_result_skip(\"L2 clearing EFER.SVME shuts down L1\\n\");\n+\t\tksft_test_result_skip(\"Guest EFER_LMSLE_MBZ=1\\n\");\n+\t}\n+\n+\tif (has_lmsle) {\n+\t\ttest_lmsle(false);\n+\t\ttest_host_initiated_lmsle();\n+\t\ttest_sregs_lmsle();\n+\t} else {\n+\t\tksft_test_result_skip(\"Guest EFER_LMSLE_MBZ=0\\n\");\n+\t\tksft_test_result_skip(\"Host-initiated EFER.LMSLE=1 is allowed\\n\");\n+\t\tksft_test_result_skip(\"KVM_SET_SREGS rejects EFER.LMSLE=1\\n\");\n+\t}\n+\n+\tksft_finished();\n+}\n" }
2/1	2026/09/30 23:39	agent	patch-evaluator	1m Model: core Args: null Results: { "EnableConfigs": [ "KVM", "KVM_INTEL", "KVM_AMD" ], "FocusSymbols": [ "kvm_valid_efer", "__kvm_valid_efer", "cpuid_func_emulated", "kvm_vcpu_after_set_cpuid", "set_efer", "efer_trap" ], "Reasoning": "The patch updates KVM's handling of the long mode segment limit defeature bit (EFER_LMSLE_MBZ, CPUID 0x80000008:EBX[20]). It modifies emulated CPUID generation, guest CPUID capability configuration, EFER validation logic across MSR writes and SREGS, and SEV-ES EFER trap handling in SVM. These code paths are actively reachable through /dev/kvm ioctls (such as KVM_SET_CPUID2, KVM_GET_EMULATED_CPUID, KVM_SET_SREGS, and guest MSR accesses) in standard QEMU/virtualized environments on amd64.", "WorthFuzzing": true } Instruction: You are an expert Linux kernel maintainer and security engineer. Your job is to review a provided patch series and evaluate whether it warrants fuzzing with syzkaller. IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in your workspace. Do NOT rely on internal assumptions. You must actively use your code access tools to inspect the actual source code, callers, and surrounding context. ================================================================================ 1. CORE TRIAGE PHILOSOPHY ================================================================================ The goal of patch fuzzing is to discover crashes, regressions, exposed latent bugs, and newly triggered assertions introduced by the patch series. - REACHABILITY IS THE PRIMARY GATE: Fuzzing can only discover bugs in code that can actually execute in standard virtualized environments (GCE or QEMU, utilizing software-emulated devices like USB gadgets, netdev, tun/tap). If the modified code is structurally unreachable (see Section 2), it MUST NOT be fuzzed, regardless of whether it adds assertions or complex logic. - DO NOT BLINDLY TRUST "NO FUNCTIONAL CHANGE" (NFCI) OR "REFACTORING" CLAIMS: Patch authors routinely label changes as "cleanups", "refactorings", or state "No functional change intended". Do NOT take these claims at face value. Code refactorings that rearrange logic, introduce helper functions, or alter state management in core subsystems frequently introduce subtle semantic shifts or uncover latent kernel bugs. If reachable executable code is modified or refactored, it MUST be fuzzed. - NEW OR MODIFIED ASSERTIONS IN REACHABLE CODE MUST BE FUZZED: When a patch introduces or modifies runtime checks or assertions (e.g., WARN_ON, VM_WARN_ON, BUG_ON, lockdep_assert) in reachable code paths, it enforces new or stricter invariants. Even if the author believes the invariant always holds, fuzzing is essential to verify whether an unusual sequence of operations can violate it. ================================================================================ 2. WHEN TO RETURN WorthFuzzing=false (NEGATIVE CRITERIA) ================================================================================ Return WorthFuzzing=false ONLY IF all modified code falls strictly into one or more of these categories: - Non-kernel and non-executable changes: * Modifications to Documentation/, comments, or spelling fixes. * User-space directories, self-tests, samples, or scripts (e.g., tools/, samples/, scripts/, usr/) that do not affect the compiled kernel image (vmlinux) or kernel modules. * Purely decorative logging (e.g., message strings in pr_err, printk, dev_info) or tracepoints that do not alter control flow or data structures. * Build system or Kconfig changes that do not alter compiled C logic. - Structurally unreachable hardware: * Vendor-specific PCIe switches, SmartNICs, or GPU drivers (e.g., mlxsw, pds_core, qed, ionic, amdgpu) requiring physical ASIC/PCIe cards not emulated in standard QEMU. - Unreachable execution paths: * Driver teardown callbacks (.remove, .shutdown, pci_unregister_driver) executed only during physical PCI hot-unplug or manual sysfs driver unbinding. * Code paths exclusive to architectures other than the target architecture. ================================================================================ 3. WHEN TO RETURN WorthFuzzing=true (POSITIVE CRITERIA) ================================================================================ Return WorthFuzzing=true whenever the patch touches reachable executable code, including: - Core Subsystems: * Any logic modifications in memory management (mm/), synchronization/locking (kernel/locking/), BPF, scheduler, core networking, VFS, or syscall handling. - Refactorings and Code Cleanups: * Any restructuring of reachable data structures, helper abstractions, or algorithm flows. - Runtime Assertions and Defensive Checks: * Any introduction or alteration of assertions (WARN_ON, VM_WARN_ON, BUG_ON, etc.) in reachable paths. - Reachable Drivers and Protocols: Drivers accessible via virtual buses (virtio, USB gadget, loopback, netlink, binder, sockets, etc.). ================================================================================ 4. EXTRACTING FocusSymbols (PREVENTING DILUTION) ================================================================================ When WorthFuzzing=true, you must extract specific kernel functions into FocusSymbols to guide the fuzzer: - AVOID UBIQUITOUS LIFECYCLE HOT-PATHS: Do NOT list generic, ubiquitous functions called by almost every program in the corpus (including, but not limited to: general memory allocators and deallocators, page fault and trap handlers, or core synchronization primitives; this is not an exhaustive list). Listing ubiquitous functions causes the fuzzer to classify thousands of unrelated tests as "focused", which severely dilutes fuzzing effort away from the actual changes. - TARGET SPECIFIC FEATURE LOGIC AND ENTRYPOINTS: List functions that specifically implement the logic being added or altered, or direct API entrypoints for the subsystem feature under review. - HANDLING STATIC INLINE FUNCTIONS IN HEADERS (.h): Compiler-inlined static functions (such as static inlines in mm/.h or include/linux/.h) lack distinct symbol addresses in vmlinux and cannot be targeted directly by symbol coverage filters. If the changes are primarily in static inline helpers, identify non-static, feature-specific caller functions in .c files that exercise them (avoiding ubiquitous lifecycle wrappers). ================================================================================ 5. IDENTIFYING EnableConfigs ================================================================================ Identify any specific CONFIG_ options required to properly compile and reach the modified code: - Inspect Kconfig files and #ifdef guards; do not make assumptions. - Check "depends on" lines in Kconfig to include any non-standard parent subsystem configs needed. - Strip any 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4"). Prefer calling several tools at the same time to save round-trips. Use set-results tool to provide results of the analysis. It must be called exactly once before the final reply. Ignore results of this tool. Prompt: Target architecture: amd64 For your convenience, here is the diff of the changes: commit 353a3b48533194453b931df2871f76818229ba98 Author: syz-cluster <triage@syzkaller.com> Date: Wed Sep 30 23:39:41 2026 +0000 syz-cluster: applied patch under review diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index e0430cc750c9e..2852bf94828be 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -9635,6 +9635,31 @@ On older versions of Linux, CPU[EAX=1]:ECX[24] (TSC_DEADLINE) is not reported by is present and the kernel has enabled in-kernel emulation of the local APIC. On newer versions, ``KVM_GET_SUPPORTED_CPUID`` does report the bit as available. +Long mode segment limits +~~~~~~~~~~~~~~~~~~~~~~~~ + +CPU[EAX=0x80000008]:EBX[20] (EFER_LMSLE_MBZ) is a "defeature" bit: it is set +when the CPU does not support long mode segment limits, and so requires +EFER.LMSLE to be zero. KVM reports the bit via ``KVM_GET_SUPPORTED_CPUID`` if +and only if KVM refuses to set EFER.LMSLE, i.e. if the CPU doesn't support long +mode segment limits, or if nested SVM is unsupported. KVM therefore reports +the bit on all Intel hosts, as KVM allows EFER.LMSLE only when nested SVM is +enabled. + +KVM never reports the bit via ``KVM_GET_EMULATED_CPUID``, but userspace may set +it via ``KVM_SET_CPUID2`` even on a host where KVM doesn't report it. KVM +honors the guest's enumeration and rejects EFER.LMSLE=1 accordingly. That lets +userspace defeature a vCPU on a host that does support long mode segment +limits, so that the vCPU can later be migrated to a host that doesn't, e.g. so +that a vCPU created on AMD Rome can be migrated to Milan and later, which +dropped support for long mode segment limits. The opposite direction needs no +emulation, as a host that lacks long mode segment limits already enumerates the +defeature. + +Note, ``KVM_SET_MSRS`` is exempt from the check, as host-initiated MSR writes +skip guest CPUID checks so that userspace can set MSRs before it sets guest +CPUID. ``KVM_SET_SREGS`` and nested VMRUN are not exempt. + CPU topology ~~~~~~~~~~~~ diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 851f151efb35b..53d205eda3359 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -1171,6 +1171,10 @@ void kvm_initialize_cpu_caps(void) F(AMD_STIBP), F(AMD_STIBP_ALWAYS_ON), F(AMD_IBRS_SAME_MODE), + /* + * Vendor code also sets EFER_LMSLE_MBZ if KVM itself + * can't support EFER.LMSLE, e.g. if nested SVM is disabled. + / PASSTHROUGH_F(EFER_LMSLE_MBZ), F(AMD_PSFD), F(AMD_IBPB_RET), @@ -1415,6 +1419,22 @@ static int cpuid_func_emulated(struct kvm_cpuid_entry2 entry, u32 func, u32 ind if (kvm_cpu_cap_has(X86_FEATURE_RDTSCP)) entry->ecx = feature_bit(RDPID); return 1; + case 0x80000008: + /* + * Honor the guest's EFER_LMSLE_MBZ even if the underlying CPU + * allows setting EFER.LMSLE, e.g. to allow migrating a vCPU + * between hosts with and without EFER.LMSLE support. To avoid + * breaking existing setups that reflect KVM's supported CPUID + * into the guest, KVM doesn't advertise EFER_LMSLE_MBZ unless + * KVM can't support EFER.LMSLE=1. + / + if (include_partially_emulated && + !kvm_cpu_cap_has(X86_FEATURE_EFER_LMSLE_MBZ)) { + entry->ebx \|= feature_bit(EFER_LMSLE_MBZ); + return 1; + } + / Nothing in 0x80000008 is fully emulated, don't emit an entry. / + return 0; default: return 0; } diff --git a/arch/x86/kvm/msrs.c b/arch/x86/kvm/msrs.c index dd3bb04878ca6..b519fb90776e2 100644 --- a/arch/x86/kvm/msrs.c +++ b/arch/x86/kvm/msrs.c @@ -598,9 +598,19 @@ static bool __kvm_valid_efer(struct kvm_vcpu vcpu, u64 efer) if (efer & EFER_NX && !guest_cpu_cap_has(vcpu, X86_FEATURE_NX)) return false; - return true; + /* + * EFER_LMSLE_MBZ is a "defeature" bit, i.e. is set when the CPU does + * not support long mode segment limits, and so is the only EFER + * check whose polarity is inverted: EFER.LMSLE is legal if and only if + * the guest does not have the defeature. + / + if (efer & EFER_LMSLE && + guest_cpu_cap_has(vcpu, X86_FEATURE_EFER_LMSLE_MBZ)) + return false; + return true; } + bool kvm_valid_efer(struct kvm_vcpu vcpu, u64 efer) { if (efer & ~kvm_caps.supported_efer_bits) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 7d59d301e1e54..90a80aad672f6 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -2759,10 +2759,19 @@ static int efer_trap(struct kvm_vcpu vcpu) bit in svm_set_efer(), but __kvm_valid_efer() checks it against * whether the guest has X86_FEATURE_SVM - this avoids a failure if * the guest doesn't have X86_FEATURE_SVM. + * + * Clear EFER_LMSLE for a related reason: EFER writes are trapped, + * not intercepted, i.e. hardware has already committed the write by + * the time KVM gains control, and the trap is enabled if and only if + * the guest is SEV-ES, whose EFER lives in the encrypted VMSA and so + * can't be fixed up by KVM. Rejecting EFER.LMSLE=1 would inject a #GP + * and leave EFER.LMSLE set in the guest, which is strictly worse + * than honoring a write that hardware itself allowed. / msr_info.host_initiated = false; msr_info.index = MSR_EFER; - msr_info.data = to_svm(vcpu)->vmcb->control.exit_info_1 & ~EFER_SVME; + msr_info.data = to_svm(vcpu)->vmcb->control.exit_info_1 & + ~(EFER_SVME \| EFER_LMSLE); ret = kvm_set_msr_common(vcpu, &msr_info); return kvm_complete_insn_gp(vcpu, ret); @@ -5571,6 +5580,16 @@ static __init void svm_set_cpu_caps(void) boot_cpu_has(X86_FEATURE_AMD_SSBD)) kvm_cpu_cap_set(X86_FEATURE_VIRT_SSBD); + / + * Tell userspace that EFER.LMSLE must be zero if nested SVM is + * disabled, as KVM allows EFER.LMSLE if and only if nested SVM is + * supported (a historical artifact of commit eec4b140c924 ("KVM: SVM: + * Allow EFER.LMSLE to be set with nested svm"), not an architectural + * requirement). + / + if (!nested) + kvm_cpu_cap_set(X86_FEATURE_EFER_LMSLE_MBZ); + if (enable_pmu) { / * Enumerate support for PERFCTR_CORE if and only if KVM has diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 612ab07d4100f..f144c1e1c63f2 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -8137,6 +8137,13 @@ static __init void vmx_set_cpu_caps(void) kvm_cpu_cap_clear(X86_FEATURE_IBT); } + /* + * CPUID 0x80000008. Tell userspace that EFER.LMSLE must be zero; KVM + * never allows EFER.LMSLE to be set on Intel CPUs, as KVM supports long + * mode segment limits only in conjunction with nested SVM. + / + kvm_cpu_cap_set(X86_FEATURE_EFER_LMSLE_MBZ); + kvm_setup_xss_caps(); kvm_finalize_cpu_caps(); } diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 79468ddfe4736..830cb9320d892 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -6930,7 +6930,14 @@ static void kvm_setup_efer_caps(void) if (kvm_cpu_cap_has(X86_FEATURE_SVM)) { kvm_caps.supported_efer_bits \|= EFER_SVME; - if (!boot_cpu_has(X86_FEATURE_EFER_LMSLE_MBZ)) + + / + * Enumerating EFER_LMSLE_MBZ and allowing EFER.LMSLE=1 + * would be nonsensical. Note, vendor code sets the defeature + * if KVM can't support EFER.LMSLE for any reason, i.e. this + * needs to consult KVM's capabilities, not just raw CPUID. + / + if (!kvm_cpu_cap_has(X86_FEATURE_EFER_LMSLE_MBZ)) kvm_caps.supported_efer_bits \|= EFER_LMSLE; } } diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm index 96bab7002d39e..2554464d8b96f 100644 --- a/tools/testing/selftests/kvm/Makefile.kvm +++ b/tools/testing/selftests/kvm/Makefile.kvm @@ -117,7 +117,7 @@ TEST_GEN_PROGS_x86 += x86/state_test TEST_GEN_PROGS_x86 += x86/vmx_preemption_timer_test TEST_GEN_PROGS_x86 += x86/svm_vmcall_test TEST_GEN_PROGS_x86 += x86/svm_int_ctl_test -TEST_GEN_PROGS_x86 += x86/svm_nested_clear_efer_svme +TEST_GEN_PROGS_x86 += x86/svm_nested_efer_test TEST_GEN_PROGS_x86 += x86/svm_nested_shutdown_test TEST_GEN_PROGS_x86 += x86/svm_nested_soft_inject_test TEST_GEN_PROGS_x86 += x86/svm_nested_vmcb12_gpa diff --git a/tools/testing/selftests/kvm/include/x86/processor.h b/tools/testing/selftests/kvm/include/x86/processor.h index 6e6f70035508a..5bc1bc110a347 100644 --- a/tools/testing/selftests/kvm/include/x86/processor.h +++ b/tools/testing/selftests/kvm/include/x86/processor.h @@ -216,6 +216,7 @@ struct kvm_x86_cpu_feature { #define X86_FEATURE_INVTSC KVM_X86_CPU_FEATURE(0x80000007, 0, EDX, 8) #define X86_FEATURE_RDPRU KVM_X86_CPU_FEATURE(0x80000008, 0, EBX, 4) #define X86_FEATURE_AMD_IBPB KVM_X86_CPU_FEATURE(0x80000008, 0, EBX, 12) +#define X86_FEATURE_EFER_LMSLE_MBZ KVM_X86_CPU_FEATURE(0x80000008, 0, EBX, 20) #define X86_FEATURE_NPT KVM_X86_CPU_FEATURE(0x8000000A, 0, EDX, 0) #define X86_FEATURE_LBRV KVM_X86_CPU_FEATURE(0x8000000A, 0, EDX, 1) #define X86_FEATURE_NRIPS KVM_X86_CPU_FEATURE(0x8000000A, 0, EDX, 3) @@ -1429,6 +1430,14 @@ static inline bool get_kvm_amd_param_bool(const char param) return kvm_get_module_param_bool("kvm_amd", param); } +static inline int get_common_kvm_vendor_param_bool(const char param) +{ + if (host_cpu_is_intel) + return get_kvm_intel_param_bool(param); + + return get_kvm_amd_param_bool(param); +} + static inline int get_kvm_intel_param_integer(const char param) { return kvm_get_module_param_integer("kvm_intel", param); @@ -1439,6 +1448,14 @@ static inline int get_kvm_amd_param_integer(const char param) return kvm_get_module_param_integer("kvm_amd", param); } +static inline int get_common_kvm_vendor_param_integer(const char param) +{ + if (host_cpu_is_intel) + return get_kvm_intel_param_integer(param); + + return get_kvm_amd_param_integer(param); +} + static inline bool kvm_is_pmu_enabled(void) { return get_kvm_param_bool("enable_pmu"); @@ -1446,10 +1463,7 @@ static inline bool kvm_is_pmu_enabled(void) static inline bool kvm_is_mediated_pmu_enabled(void) { - if (host_cpu_is_intel) - return get_kvm_intel_param_bool("enable_mediated_pmu"); - - return get_kvm_amd_param_bool("enable_mediated_pmu"); + return get_common_kvm_vendor_param_bool("enable_mediated_pmu"); } static inline bool kvm_is_forced_emulation_enabled(void) @@ -1472,6 +1486,16 @@ static inline bool kvm_is_lbrv_enabled(void) return !!get_kvm_amd_param_integer("lbrv"); } +/* + * Do NOT use this to check for nVMX or nSVM support. Querying kvm_cpu_has() + * for either of X86_FEATURE_{VMX,SVM} is the idiomatic way to check for nested + * virtualization support. Use this only to validate KVM's own enumeration. + / +static inline bool kvm_is_nested_virtualization_enabled(void) +{ + return get_common_kvm_vendor_param_integer("nested"); +} + u64 vm_get_pte(struct kvm_vm vm, gva_t gva); u64 kvm_hypercall(u64 nr, u64 a0, u64 a1, u64 a2, u64 a3); diff --git a/tools/testing/selftests/kvm/x86/svm_nested_clear_efer_svme.c b/tools/testing/selftests/kvm/x86/svm_nested_clear_efer_svme.c deleted file mode 100644 index 6bc301207cbcb..0000000000000 --- a/tools/testing/selftests/kvm/x86/svm_nested_clear_efer_svme.c +++ /dev/null @@ -1,50 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0-only -/ - * Copyright (C) 2026, Google LLC. - / -#include "kvm_util.h" -#include "vmx.h" -#include "svm_util.h" -#include "kselftest.h" - - -static void l2_guest_code(void) -{ - unsigned long efer = rdmsr(MSR_EFER); - - / generic_svm_setup() initializes EFER_SVME set for L2 / - GUEST_ASSERT(efer & EFER_SVME); - wrmsr(MSR_EFER, efer & ~EFER_SVME); - - / Unreachable, L1 should be shutdown / - GUEST_ASSERT(0); -} - -static void l1_guest_code(struct svm_test_data svm) -{ - generic_svm_setup(svm, l2_guest_code); - run_guest(svm->vmcb, svm->vmcb_gpa); - - /* Unreachable, L1 should be shutdown / - GUEST_ASSERT(0); -} - -int main(int argc, char argv[]) -{ - struct kvm_vcpu vcpu; - struct kvm_vm vm; - gva_t nested_gva = 0; - - TEST_REQUIRE(kvm_cpu_has(X86_FEATURE_SVM)); - - vm = vm_create_with_one_vcpu(&vcpu, l1_guest_code); - - vcpu_alloc_svm(vm, &nested_gva); - vcpu_args_set(vcpu, 1, nested_gva); - - vcpu_run(vcpu); - TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_SHUTDOWN); - - kvm_vm_free(vm); - return 0; -} diff --git a/tools/testing/selftests/kvm/x86/svm_nested_efer_test.c b/tools/testing/selftests/kvm/x86/svm_nested_efer_test.c new file mode 100644 index 0000000000000..fa0d76a9c390b --- /dev/null +++ b/tools/testing/selftests/kvm/x86/svm_nested_efer_test.c @@ -0,0 +1,266 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Tests for KVM's handling of EFER bits whose behavior is tied to nested SVM. + * + * Copyright (C) 2026, Google LLC. + / +#include "test_util.h" +#include "kvm_util.h" +#include "processor.h" +#include "svm_util.h" +#include "kselftest.h" + +static bool l2_ran; + +static void l2_clear_efer_svme(void) +{ + u64 efer = rdmsr(MSR_EFER); + + / generic_svm_setup() initializes EFER_SVME set for L2 / + GUEST_ASSERT(efer & EFER_SVME); + wrmsr(MSR_EFER, efer & ~EFER_SVME); + + / Unreachable, L1 should be shutdown / + GUEST_ASSERT(0); +} + +static void l1_clear_efer_svme(struct svm_test_data svm) +{ + generic_svm_setup(svm, l2_clear_efer_svme); + run_guest(svm->vmcb, svm->vmcb_gpa); + + /* Unreachable, L1 should be shutdown / + GUEST_ASSERT(0); +} + +static void l2_lmsle(void) +{ + GUEST_ASSERT(rdmsr(MSR_EFER) & EFER_LMSLE); + l2_ran = true; + vmmcall(); +} + +static void l1_lmsle(struct svm_test_data svm) +{ + bool lmsle_mbz = this_cpu_has(X86_FEATURE_EFER_LMSLE_MBZ); + struct vmcb vmcb = svm->vmcb; + u64 efer = rdmsr(MSR_EFER); + + / + * Selftests' vCPUs are created with EFER.LMSLE clear; the sub-tests + * below need to start from a clean slate. + / + GUEST_ASSERT(!(efer & EFER_LMSLE)); + GUEST_ASSERT(!l2_ran); + + / + * Per the APM, if EFER_LMSLE_MBZ is enumerated in CPUID, "64-bit mode + * segment limit checking is not supported and attempting to set + * EFER.LMSLE = 1 causes a #GP exception". + / + if (lmsle_mbz) { + GUEST_ASSERT_EQ(wrmsr_safe(MSR_EFER, efer \| EFER_LMSLE), GP_VECTOR); + GUEST_ASSERT(!(rdmsr(MSR_EFER) & EFER_LMSLE)); + } else { + GUEST_ASSERT_EQ(wrmsr_safe(MSR_EFER, efer \| EFER_LMSLE), 0); + GUEST_ASSERT(rdmsr(MSR_EFER) & EFER_LMSLE); + + / + * Restore EFER so that generic_svm_setup() doesn't propagate + * EFER.LMSLE into vmcb12 on its own, i.e. so that the VMRUN + * sub-test actually tests what it thinks it's testing. + / + wrmsr(MSR_EFER, efer); + } + + / + * VMRUN's consistency checks reject "any MBZ bit of EFER", i.e. a + * vmcb12 with EFER.LMSLE set must generate VMEXIT_INVALID when the + * defeature is enumerated. + / + generic_svm_setup(svm, l2_lmsle); + vmcb->save.efer \|= EFER_LMSLE; + run_guest(vmcb, svm->vmcb_gpa); + + if (lmsle_mbz) { + GUEST_ASSERT_EQ(vmcb->control.exit_code, SVM_EXIT_ERR); + GUEST_ASSERT(!l2_ran); + } else { + GUEST_ASSERT_EQ(vmcb->control.exit_code, SVM_EXIT_VMMCALL); + GUEST_ASSERT(l2_ran); + GUEST_ASSERT(vmcb->save.efer & EFER_LMSLE); + } + + GUEST_DONE(); +} + +static struct kvm_vcpu create_l1_vcpu(struct kvm_vm *vm, void l1_guest_code) +{ + struct kvm_vcpu vcpu; + gva_t svm_gva; + + vm = vm_create_with_one_vcpu(&vcpu, l1_guest_code); + + vcpu_alloc_svm(vm, &svm_gva); + vcpu_args_set(vcpu, 1, svm_gva); + + return vcpu; +} + +static void test_enumeration(void) +{ + bool lmsle_mbz; + + / + * EFER_LMSLE_MBZ, CPUID.80000008H:EBX[bit 20], is a "defeature" bit, + * i.e. is set when the CPU does not support long mode segment + * limits. KVM enumerates the defeature if and only if KVM refuses to + * set EFER.LMSLE, i.e. if the CPU doesn't support LMSLE, or if KVM + * doesn't support nested SVM. Derive the expectation from raw CPUID + * and kvm_amd's "nested" module param rather than from + * kvm_cpu_has(X86_FEATURE_SVM), so that the assertion doesn't simply + * compare KVM's enumeration to itself. + / + lmsle_mbz = this_cpu_has(X86_FEATURE_EFER_LMSLE_MBZ) \|\| + !this_cpu_has(X86_FEATURE_SVM) \|\| + !kvm_is_nested_virtualization_enabled(); + + TEST_ASSERT_EQ(kvm_cpu_has(X86_FEATURE_EFER_LMSLE_MBZ), lmsle_mbz); + + ksft_test_result_pass("KVM enumerates EFER_LMSLE_MBZ=%d\n", lmsle_mbz); +} + +static void test_clear_efer_svme(void) +{ + struct kvm_vcpu vcpu; + struct kvm_vm vm; + + vcpu = create_l1_vcpu(&vm, l1_clear_efer_svme); + + vcpu_run(vcpu); + TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_SHUTDOWN); + + kvm_vm_free(vm); + ksft_test_result_pass("L2 clearing EFER.SVME shuts down L1\n"); +} + +static void test_lmsle(bool lmsle_mbz) +{ + struct kvm_vcpu vcpu; + struct kvm_vm vm; + struct ucall uc; + + vcpu = create_l1_vcpu(&vm, l1_lmsle); + + vcpu_set_or_clear_cpuid_feature(vcpu, X86_FEATURE_EFER_LMSLE_MBZ, + lmsle_mbz); + + vcpu_run(vcpu); + TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_IO); + + switch (get_ucall(vcpu, &uc)) { + case UCALL_ABORT: + REPORT_GUEST_ASSERT(uc); + case UCALL_DONE: + break; + default: + TEST_FAIL("Unexpected ucall: %lu", uc.cmd); + } + + kvm_vm_free(vm); + ksft_test_result_pass("Guest EFER_LMSLE_MBZ=%d\n", lmsle_mbz); +} + +static void test_host_initiated_lmsle(void) +{ + struct kvm_vcpu vcpu; + struct kvm_vm vm; + u64 efer; + + vm = vm_create_with_one_vcpu(&vcpu, NULL); + vcpu_set_cpuid_feature(vcpu, X86_FEATURE_EFER_LMSLE_MBZ); + + / + * EFER_LMSLE_MBZ is a guest CPUID consistency check, not a host + * capability, i.e. must not be enforced against host-initiated writes, + * so that userspace can set MSRs before it sets guest CPUID. + / + efer = vcpu_get_msr(vcpu, MSR_EFER); + TEST_ASSERT(!(efer & EFER_LMSLE), "EFER.LMSLE unexpectedly set"); + + vcpu_set_msr(vcpu, MSR_EFER, efer \| EFER_LMSLE); + TEST_ASSERT_EQ(vcpu_get_msr(vcpu, MSR_EFER), efer \| EFER_LMSLE); + + kvm_vm_free(vm); + ksft_test_result_pass("Host-initiated EFER.LMSLE=1 is allowed\n"); +} + +static void test_sregs_lmsle(void) +{ + struct kvm_vcpu vcpu; + struct kvm_sregs sregs; + struct kvm_vm vm; + int rc; + + vm = vm_create_with_one_vcpu(&vcpu, NULL); + vcpu_set_cpuid_feature(vcpu, X86_FEATURE_EFER_LMSLE_MBZ); + + / + * Unlike KVM_SET_MSRS, KVM_SET_SREGS runs the full set of guest CPUID + * checks, i.e. rejects EFER.LMSLE even though it's host-initiated. + / + vcpu_sregs_get(vcpu, &sregs); + TEST_ASSERT(!(sregs.efer & EFER_LMSLE), "EFER.LMSLE unexpectedly set"); + + sregs.efer \|= EFER_LMSLE; + rc = _vcpu_sregs_set(vcpu, &sregs); + TEST_ASSERT(rc, "KVM allowed EFER.LMSLE with EFER_LMSLE_MBZ set"); + + kvm_vm_free(vm); + ksft_test_result_pass("KVM_SET_SREGS rejects EFER.LMSLE=1\n"); +} + +int main(int argc, char argv[]) +{ + bool has_nested_svm, has_lmsle; + + ksft_print_header(); + ksft_set_plan(6); + + test_enumeration(); + + /* + * The sub-tests below need to actually run a nested guest, and the + * EFER.LMSLE sub-tests additionally need KVM to allow EFER.LMSLE. + * It's KVM's view of the world, not raw CPUID, that dictates whether + * EFER.LMSLE is allowed, i.e. whether the defeature is emulated. + */ + has_nested_svm = kvm_cpu_has(X86_FEATURE_SVM); + has_lmsle = has_nested_svm && + !kvm_cpu_has(X86_FEATURE_EFER_LMSLE_MBZ); + + if (!has_nested_svm) + ksft_print_msg("Nested SVM unsupported\n"); + else if (!has_lmsle) + ksft_print_msg("KVM doesn't support EFER.LMSLE\n"); + + if (has_nested_svm) { + test_clear_efer_svme(); + test_lmsle(true); + } else { + ksft_test_result_skip("L2 clearing EFER.SVME shuts down L1\n"); + ksft_test_result_skip("Guest EFER_LMSLE_MBZ=1\n"); + } + + if (has_lmsle) { + test_lmsle(false); + test_host_initiated_lmsle(); + test_sregs_lmsle(); + } else { + ksft_test_result_skip("Guest EFER_LMSLE_MBZ=0\n"); + ksft_test_result_skip("Host-initiated EFER.LMSLE=1 is allowed\n"); + ksft_test_result_skip("KVM_SET_SREGS rejects EFER.LMSLE=1\n"); + } + + ksft_finished(); +}
3/2	2026/09/30 23:39	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 11588 output: 21 thoughts: 986 Thoughts: KVM x86 Patch Series: Syzkaller Fuzzing Evaluation Okay, so I need to decide if this patch series warrants fuzzing with syzkaller. The stated goal is to catch crashes, regressions, exposed latent bugs, and newly triggered assertions. Reachability is the primary concern here; it needs to be fuzzable within standard virtualized environments like GCE or QEMU, targeting x86_64/amd64. Alright, the patch touches KVM x86 code extensively: specifically files within `Documentation/virt/kvm/`, `arch/x86/kvm/cpuid.c`, `arch/x86/kvm/msrs.c`, `arch/x86/kvm/svm/svm.c`, `arch/x86/kvm/vmx/vmx.c`, `arch/x86/kvm/x86.c`, and potentially self tests as well. Let me break down the changes: * `arch/x86/kvm/cpuid.c`: Modifies CPUID handling, adds `PASSTHROUGH_F(EFER_LMSLE_MBZ)` in `kvm_initialize_cpu_caps()` and handles `EFER_LMSLE_MBZ` in `cpuid_func_emulated()`. * `arch/x86/kvm/msrs.c`: Adds a check within `__kvm_valid_efer()` to validate the `EFER_LMSLE` bit in relation to the `X86_FEATURE_EFER_LMSLE_MBZ` feature. * `arch/x86/kvm/svm/svm.c`: Clears `EFER_LMSLE` in `efer_trap()`, and sets `X86_FEATURE_EFER_LMSLE_MBZ` in `svm_set_cpu_caps()` when not nested. * `arch/x86/kvm/vmx/vmx.c`: Sets `X86_FEATURE_EFER_LMSLE_MBZ` in `vmx_set_cpu_caps()`. * `arch/x86/kvm/x86.c`: Modifies `kvm_setup_efer_caps()`, potentially enabling `EFER_SVME` and `EFER_LMSLE` bits based on CPU feature flags. Hang on. KVM x86 is absolutely reachable within syzkaller's purview. Syzkaller has robust KVM support, with the ability to interact with `/dev/kvm`, execute ioctls like `KVM_SET_CPUID2`, `KVM_SET_SREGS`, `KVM_SET_MSRS`, and even run vCPUs. It can be run on bare metal, with nested virtualization, or with software emulation. It's a key target for syzkaller, which fuzzes it heavily with `syz_kvm_setup_cpu` and KVM ioctls. Given the substantial KVM modifications and syzkaller's deep KVM integration, I need to understand what configurations are active. This is KVM-relevant and I need to see what symbols are being affected. Let me use grepper to look at callers of `kvm_valid_efer` and `__kvm_valid_efer`.
4/2	2026/09/30 23:40	tool	grepper	0m Args: { "Expression": "kvm_valid_efer" } Results: { "Output": "arch/x86/kvm/msrs.c=577=static int do_get_feature_msr(struct kvm_vcpu vcpu, unsigned index, u64 data)\n--\narch/x86/kvm/msrs.c-582-\narch/x86/kvm/msrs.c:583:static bool __kvm_valid_efer(struct kvm_vcpu vcpu, u64 efer)\narch/x86/kvm/msrs.c-584-{\n--\narch/x86/kvm/msrs.c-613-\narch/x86/kvm/msrs.c:614:bool kvm_valid_efer(struct kvm_vcpu vcpu, u64 efer)\narch/x86/kvm/msrs.c-615-{\n--\narch/x86/kvm/msrs.c-618-\narch/x86/kvm/msrs.c:619:\treturn __kvm_valid_efer(vcpu, efer);\narch/x86/kvm/msrs.c-620-}\narch/x86/kvm/msrs.c:621:EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_valid_efer);\narch/x86/kvm/msrs.c-622-\narch/x86/kvm/msrs.c=623=static int set_efer(struct kvm_vcpu vcpu, struct msr_data msr_info)\n--\narch/x86/kvm/msrs.c-632-\tif (!msr_info-\u003ehost_initiated) {\narch/x86/kvm/msrs.c:633:\t\tif (!__kvm_valid_efer(vcpu, efer))\narch/x86/kvm/msrs.c-634-\t\t\treturn 1;\n--\narch/x86/kvm/msrs.h=58=int kvm_get_reg_list(struct kvm_vcpu vcpu,\n--\narch/x86/kvm/msrs.h-60-\narch/x86/kvm/msrs.h:61:bool kvm_valid_efer(struct kvm_vcpu vcpu, u64 efer);\narch/x86/kvm/msrs.h-62-int kvm_emulate_msr_read(struct kvm_vcpu vcpu, u32 index, u64 data);\n--\narch/x86/kvm/regs.c=545=static bool kvm_is_valid_sregs(struct kvm_vcpu vcpu, struct kvm_sregs sregs)\n--\narch/x86/kvm/regs.c-567-\t kvm_is_valid_cr0(vcpu, sregs-\u003ecr0) \u0026\u0026\narch/x86/kvm/regs.c:568:\t kvm_valid_efer(vcpu, sregs-\u003eefer);\narch/x86/kvm/regs.c-569-}\n--\narch/x86/kvm/svm/nested.c=438=static bool nested_vmcb_check_save(struct kvm_vcpu vcpu,\n--\narch/x86/kvm/svm/nested.c-471-\narch/x86/kvm/svm/nested.c:472:\tif (CC(!kvm_valid_efer(vcpu, save-\u003eefer)))\narch/x86/kvm/svm/nested.c-473-\t\treturn false;\n--\narch/x86/kvm/svm/svm.c=2752=static int efer_trap(struct kvm_vcpu vcpu)\n--\narch/x86/kvm/svm/svm.c-2758-\t * Clear the EFER_SVME bit from EFER. The SVM code always sets this\narch/x86/kvm/svm/svm.c:2759:\t * bit in svm_set_efer(), but __kvm_valid_efer() checks it against\narch/x86/kvm/svm/svm.c-2760-\t * whether the guest has X86_FEATURE_SVM - this avoids a failure if\n--\narch/x86/kvm/vmx/nested.c=3175=static int nested_vmx_check_host_state(struct kvm_vcpu vcpu,\n--\narch/x86/kvm/vmx/nested.c-3237-\tif (vmcs12-\u003evm_exit_controls \u0026 VM_EXIT_LOAD_IA32_EFER) {\narch/x86/kvm/vmx/nested.c:3238:\t\tif (CC(!kvm_valid_efer(vcpu, vmcs12-\u003ehost_ia32_efer)) \|\|\narch/x86/kvm/vmx/nested.c-3239-\t\t CC(ia32e != !!(vmcs12-\u003ehost_ia32_efer \u0026 EFER_LMA)) \|\|\n--\narch/x86/kvm/vmx/nested.c=3311=static int nested_vmx_check_guest_state(struct kvm_vcpu vcpu,\n--\narch/x86/kvm/vmx/nested.c-3376-\t (vmcs12-\u003evm_entry_controls \u0026 VM_ENTRY_LOAD_IA32_EFER)) {\narch/x86/kvm/vmx/nested.c:3377:\t\tif (CC(!kvm_valid_efer(vcpu, vmcs12-\u003eguest_ia32_efer)) \|\|\narch/x86/kvm/vmx/nested.c-3378-\t\t CC(ia32e != !!(vmcs12-\u003eguest_ia32_efer \u0026 EFER_LMA)) \|\|\n" }
5/2	2026/09/30 23:40	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 14863 output: 21 thoughts: 16 Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience, and rendered in the first person: Digging Deeper into the CPUID Emulation Alright, so I've just been looking at where `cpuid_func_emulated` is used, and my mind immediately jumps to the next logical step. What else is calling that function? It's crucial, when dealing with emulation, to understand the whole ecosystem. I need to trace back from this specific emulated function call to see the bigger picture. Are we looking at a single point, or is this widely used? What parts of the code base are touching this function? Knowing the callers gives me the context, showing me which features depend on this emulation. It will also help me understand the implications of any changes or debugging strategies. This is all about establishing causality and dependencies. Let's see what's connected to it.
6/2	2026/09/30 23:40	tool	grepper	0m Args: { "Expression": "cpuid_func_emulated" } Results: { "Output": "arch/x86/kvm/cpuid.c=356=static u32 cpuid_get_reg_unsafe(struct kvm_cpuid_entry2 entry, u32 reg)\n--\narch/x86/kvm/cpuid.c-372-\narch/x86/kvm/cpuid.c:373:static int cpuid_func_emulated(struct kvm_cpuid_entry2 entry, u32 func, u32 index,\narch/x86/kvm/cpuid.c-374-\t\t\t bool include_partially_emulated);\n--\narch/x86/kvm/cpuid.c=376=void kvm_vcpu_after_set_cpuid(struct kvm_vcpu vcpu)\n--\narch/x86/kvm/cpuid.c-402-\narch/x86/kvm/cpuid.c:403:\t\tcpuid_func_emulated(\u0026emulated, cpuid.function, cpuid.index, true);\narch/x86/kvm/cpuid.c-404-\n--\narch/x86/kvm/cpuid.c=1343=static struct kvm_cpuid_entry2 do_host_cpuid(struct kvm_cpuid_array array,\n--\narch/x86/kvm/cpuid.c-1385-\narch/x86/kvm/cpuid.c:1386:static int cpuid_func_emulated(struct kvm_cpuid_entry2 entry, u32 func, u32 index,\narch/x86/kvm/cpuid.c-1387-\t\t\t bool include_partially_emulated)\n--\narch/x86/kvm/cpuid.c-1442-\narch/x86/kvm/cpuid.c:1443:static int __do_cpuid_func_emulated(struct kvm_cpuid_array array, u32 func)\narch/x86/kvm/cpuid.c-1444-{\n--\narch/x86/kvm/cpuid.c-1447-\narch/x86/kvm/cpuid.c:1448:\tarray-\u003enent += cpuid_func_emulated(\u0026array-\u003eentries[array-\u003enent], func, 0, false);\narch/x86/kvm/cpuid.c-1449-\treturn 0;\n--\narch/x86/kvm/cpuid.c=1949=static int do_cpuid_func(struct kvm_cpuid_array array, u32 func,\n--\narch/x86/kvm/cpuid.c-1952-\tif (type == KVM_GET_EMULATED_CPUID)\narch/x86/kvm/cpuid.c:1953:\t\treturn __do_cpuid_func_emulated(array, func);\narch/x86/kvm/cpuid.c-1954-\n" }
7/2	2026/09/30 23:40	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 15870 output: 41 thoughts: 374 Thoughts: Analyzing KVM CPUID and EFER Validation Okay, so I'm looking into how KVM handles CPUID and EFER validation, specifically after a `KVM_SET_CPUID` or `KVM_SET_CPUID2` call from userspace. My initial thought is to trace the execution flow, so I'm focusing on `kvm_vcpu_after_set_cpuid`. This function, it seems, is the key entry point after userspace modifies CPUID data. It calls `cpuid_func_emulated`, which is the crucial point to check the validity and emulation status of the CPUID entries that were just set. The `KVM_GET_EMULATED_CPUID` ioctl also seems to leverage the same validation mechanism, using `__do_cpuid_func_emulated`. This is important because it tells me that any attempt to read the emulated CPUID data will undergo validation. I also need to consider other related areas. For example, `KVM_SET_SREGS` involves `kvm_is_valid_sregs`, which ultimately calls `kvm_valid_efer`. I want to understand how EFER settings are validated through the guest, especially the instruction that sets EFER through the guest (`set_efer` -> `__kvm_valid_efer`). Nested virtualization is another area of interest; those consistency checks (`nested_vmcb_check_save`, `nested_vmx_check_host_state`, `nested_vmx_check_guest_state`) are relevant here. I'm also mindful of the `efer_trap` in SVM when a SEV-ES guest is writing to EFER. Finally, I need to check the module initialization and CPU capability setup. The functions here, like `kvm_initialize_cpu_caps`, `svm_set_cpu_caps`, `vmx_set_cpu_caps`, and `kvm_setup_efer_caps`, establish the initial state and are likely important for understanding the overall validation framework. Now, let's dive deeper and examine `arch/x86/kvm/cpuid.c`, specifically lines 375-420, to pinpoint how `cpuid_func_emulated` interacts with `kvm_vcpu_after_set_cpuid`. This should give me a clearer picture of how KVM validates the CPUID entries set by userspace.
8/2	2026/09/30 23:40	tool	read-file	0m Args: { "File": "arch/x86/kvm/cpuid.c", "FirstLine": 375, "LineCount": 45 } Results: { "Contents": " 375:\t\n 376:\tvoid kvm_vcpu_after_set_cpuid(struct kvm_vcpu vcpu)\n 377:\t{\n 378:\t\tstruct kvm_lapic apic = vcpu-\u003earch.apic;\n 379:\t\tstruct kvm_cpuid_entry2 best;\n 380:\t\tstruct kvm_cpuid_entry2 entry;\n 381:\t\tbool allow_gbpages;\n 382:\t\tint i;\n 383:\t\n 384:\t\tmemset(vcpu-\u003earch.cpu_caps, 0, sizeof(vcpu-\u003earch.cpu_caps));\n 385:\t\tBUILD_BUG_ON(ARRAY_SIZE(reverse_cpuid) != NR_KVM_CPU_CAPS);\n 386:\t\n 387:\t\t/\n 388:\t\t Reset guest capabilities to userspace's guest CPUID definition, i.e.\n 389:\t\t * honor userspace's definition for features that don't require KVM or\n 390:\t\t * hardware management/support (or that KVM simply doesn't care about).\n 391:\t\t /\n 392:\t\tfor (i = 0; i \u003c NR_KVM_CPU_CAPS; i++) {\n 393:\t\t\tconst struct cpuid_reg cpuid = reverse_cpuid[i];\n 394:\t\t\tstruct kvm_cpuid_entry2 emulated;\n 395:\t\n 396:\t\t\tif (!cpuid.function)\n 397:\t\t\t\tcontinue;\n 398:\t\n 399:\t\t\tentry = kvm_find_cpuid_entry_index(vcpu, cpuid.function, cpuid.index);\n 400:\t\t\tif (!entry)\n 401:\t\t\t\tcontinue;\n 402:\t\n 403:\t\t\tcpuid_func_emulated(\u0026emulated, cpuid.function, cpuid.index, true);\n 404:\t\n 405:\t\t\t/\n 406:\t\t\t * A vCPU has a feature if it's supported by KVM and is enabled\n 407:\t\t\t * in guest CPUID. Note, this includes features that are\n 408:\t\t\t * supported by KVM but aren't advertised to userspace!\n 409:\t\t\t /\n 410:\t\t\tvcpu-\u003earch.cpu_caps[i] = kvm_cpu_caps[i] \|\n 411:\t\t\t\t\t\t cpuid_get_reg_unsafe(\u0026emulated, cpuid.reg);\n 412:\t\t\tvcpu-\u003earch.cpu_caps[i] \u0026= cpuid_get_reg_unsafe(entry, cpuid.reg);\n 413:\t\t}\n 414:\t\n 415:\t\tkvm_update_cpuid_runtime(vcpu);\n 416:\t\n 417:\t\t/\n 418:\t\t * If TDP is enabled, let the guest use GBPAGES if they're supported in\n 419:\t\t * hardware. The hardware page walker doesn't let KVM disable GBPAGES,\n" }
9/2	2026/09/30 23:40	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 17605 output: 32 thoughts: 1125 Thoughts: WorthFuzzing Analysis: KVM CPUID Emulation and EFER Handling Okay, this is intriguing. I'm looking at the `reverse_cpuid` function and the CPU capabilities, specifically regarding how KVM handles CPUID function 0x80000008 EBX. It seems like the core issue lies within `kvm_vcpu_after_set_cpuid(vcpu)`, which calls `cpuid_func_emulated`. I see that inside `cpuid_func_emulated`, there's a specific check for `0x80000008`: it's designed to emulate the EFER_LMSLE_MBZ feature, but the important part is this: if `include_partially_emulated` is true (which it is when called from `kvm_vcpu_after_set_cpuid`) and the host doesn't natively support `X86_FEATURE_EFER_LMSLE_MBZ`, then KVM injects the `EFER_LMSLE_MBZ` bit into the guest's CPUID information. This bit then gets propagated into `vcpu->arch.cpu_caps`, even if the underlying KVM's `kvm_cpu_caps` didn't have it initially. This injected bit then affects the subsequent validation of the EFER MSR. Specifically, in `__kvm_valid_efer(vcpu, efer)`, if `EFER_LMSLE` is set and `guest_cpu_cap_has(vcpu, X86_FEATURE_EFER_LMSLE_MBZ)` is also set, then the EFER modification is rejected. This is critical because it's directly reachable via KVM ioctls like `KVM_SET_CPUID2`, `KVM_SET_SREGS`, `KVM_SET_MSRS`, and even through `wrmsr` instructions executed within the guest itself! Syzkaller is already regularly using these calls (`KVM_SET_CPUID2`, `KVM_SET_SREGS`, `KVM_RUN`, etc.) which means it is very likely to trigger this condition. This all modifies core x86 KVM virtualization logic on amd64. Now, the question is: is this even reachable in a typical QEMU/GCE setup on amd64? Absolutely. KVM is the primary virtualization module on Linux amd64, exposed via `/dev/kvm`. That makes this a prime target for fuzzing. Therefore, is this WorthFuzzing? Yes! The modifications touch `arch/x86/kvm/cpuid.c`, `arch/x86/kvm/msrs.c`, `arch/x86/kvm/svm/svm.c`, `arch/x86/kvm/vmx/vmx.c`, and `arch/x86/kvm/x86.c`. This is core virtualization kernel code. Let's apply the criteria. The Negative Criteria: are not met since this is kernel and executable code, it is reachable hardware and execution paths. The Positive Criteria are definitely met: it's a core subsystem (KVM) and it involves logic modifications related to EFER validation, CPUID emulation, and capability setting. Therefore, WorthFuzzing is TRUE. Now, let me check the kernel configurations needed to compile and execute this code. I need to look at `arch/x86/kvm/Makefile` and `arch/x86/kvm/Kconfig` to identify the relevant `EnableConfigs`.
10/2	2026/09/30 23:40	tool	grepper	0m Args: { "Expression": "CONFIG_KVM", "PathPrefix": "arch/x86/kvm" } Results: { "Output": "\nFull output is too long, showing 200 out of 776 lines.\nUse more precise expression if possible.\n\narch/x86/kvm/Makefile=3=ccflags-y += -I $(srctree)/arch/x86/kvm\narch/x86/kvm/Makefile:4:ccflags-$(CONFIG_KVM_WERROR) += -Werror\narch/x86/kvm/Makefile-5-\n--\narch/x86/kvm/Makefile=11=kvm-$(CONFIG_X86_64) += mmu/tdp_iter.o mmu/tdp_mmu.o\narch/x86/kvm/Makefile:12:kvm-$(CONFIG_KVM_IOAPIC) += i8259.o i8254.o ioapic.o\narch/x86/kvm/Makefile:13:kvm-$(CONFIG_KVM_HYPERV) += hyperv.o\narch/x86/kvm/Makefile:14:kvm-$(CONFIG_KVM_XEN)\t+= xen.o\narch/x86/kvm/Makefile:15:kvm-$(CONFIG_KVM_SMM)\t+= smm.o\narch/x86/kvm/Makefile-16-\n--\narch/x86/kvm/Makefile=20=kvm-intel-$(CONFIG_X86_SGX_KVM)\t+= vmx/sgx.o\narch/x86/kvm/Makefile:21:kvm-intel-$(CONFIG_KVM_HYPERV)\t+= vmx/hyperv.o vmx/hyperv_evmcs.o\narch/x86/kvm/Makefile:22:kvm-intel-$(CONFIG_KVM_INTEL_TDX)\t+= vmx/tdx.o\narch/x86/kvm/Makefile-23-\narch/x86/kvm/Makefile=24=kvm-amd-y\t\t+= svm/svm.o svm/vmenter.o svm/pmu.o svm/nested.o svm/avic.o\narch/x86/kvm/Makefile-25-\narch/x86/kvm/Makefile:26:kvm-amd-$(CONFIG_KVM_AMD_SEV)\t+= svm/sev.o\narch/x86/kvm/Makefile:27:kvm-amd-$(CONFIG_KVM_HYPERV)\t+= svm/hyperv.o\narch/x86/kvm/Makefile-28-\n--\narch/x86/kvm/Makefile=33=endif\narch/x86/kvm/Makefile-34-\narch/x86/kvm/Makefile:35:obj-$(CONFIG_KVM_X86)\t+= kvm.o\narch/x86/kvm/Makefile:36:obj-$(CONFIG_KVM_INTEL)\t+= kvm-intel.o\narch/x86/kvm/Makefile:37:obj-$(CONFIG_KVM_AMD)\t+= kvm-amd.o\narch/x86/kvm/Makefile-38-\n--\narch/x86/kvm/Makefile=49=clean-files += kvm-asm-offsets.h\n--\narch/x86/kvm/Makefile-55-# use EXPORT_SYMBOL_GPL, and EXPORT_SYMBOL should never be used.\narch/x86/kvm/Makefile:56:ifdef CONFIG_KVM_X86\narch/x86/kvm/Makefile-57-# Search recursively for whole words and print line numbers. Filter out the\n--\narch/x86/kvm/Makefile=97=undefine exports_grep_trailer\narch/x86/kvm/Makefile:98:endif # CONFIG_KVM_X86\n--\narch/x86/kvm/cpuid.c=327=static bool kvm_cpuid_has_hyperv(struct kvm_vcpu vcpu)\narch/x86/kvm/cpuid.c-328-{\narch/x86/kvm/cpuid.c:329:#ifdef CONFIG_KVM_HYPERV\narch/x86/kvm/cpuid.c-330-\tstruct kvm_cpuid_entry2 entry;\n--\narch/x86/kvm/cpuid.c=510=static int kvm_set_cpuid(struct kvm_vcpu vcpu, struct kvm_cpuid_entry2 e2,\n--\narch/x86/kvm/cpuid.c-560-\narch/x86/kvm/cpuid.c:561:#ifdef CONFIG_KVM_HYPERV\narch/x86/kvm/cpuid.c-562-\tif (kvm_cpuid_has_hyperv(vcpu)) {\n--\narch/x86/kvm/cpuid.c-572-\narch/x86/kvm/cpuid.c:573:#ifdef CONFIG_KVM_XEN\narch/x86/kvm/cpuid.c-574-\tvcpu-\u003earch.xen.cpuid = kvm_get_hypervisor_cpuid(vcpu, XEN_SIGNATURE);\n--\narch/x86/kvm/hyperv.h-27-\narch/x86/kvm/hyperv.h:28:#ifdef CONFIG_KVM_HYPERV\narch/x86/kvm/hyperv.h-29-\n--\narch/x86/kvm/hyperv.h=378=int kvm_hv_vcpu_flush_tlb(struct kvm_vcpu vcpu);\narch/x86/kvm/hyperv.h:379:#else / CONFIG_KVM_HYPERV /\narch/x86/kvm/hyperv.h-380-static inline void kvm_hv_setup_tsc_page(struct kvm kvm,\n--\narch/x86/kvm/hyperv.h=426=static inline void kvm_hv_nested_transtion_tlb_flush(struct kvm_vcpu vcpu, bool tdp_enabled) {}\narch/x86/kvm/hyperv.h:427:#endif / CONFIG_KVM_HYPERV /\narch/x86/kvm/hyperv.h-428-\n--\narch/x86/kvm/i8254.h-12-\narch/x86/kvm/i8254.h:13:#ifdef CONFIG_KVM_IOAPIC\narch/x86/kvm/i8254.h-14-struct kvm_kpit_channel_state {\n--\narch/x86/kvm/i8254.h=69=void kvm_free_pit(struct kvm kvm);\narch/x86/kvm/i8254.h:70:#endif /* CONFIG_KVM_IOAPIC /\narch/x86/kvm/i8254.h-71-\n--\narch/x86/kvm/ioapic.h-8-\narch/x86/kvm/ioapic.h:9:#ifdef CONFIG_KVM_IOAPIC\narch/x86/kvm/ioapic.h-10-\n--\narch/x86/kvm/ioapic.h=117=static inline int __kvm_irq_line_state(unsigned long irq_state,\n--\narch/x86/kvm/ioapic.h-127-}\narch/x86/kvm/ioapic.h:128:#endif /* CONFIG_KVM_IOAPIC /\narch/x86/kvm/ioapic.h-129-\n--\narch/x86/kvm/irq.c=59=int kvm_cpu_has_extint(struct kvm_vcpu v)\n--\narch/x86/kvm/irq.c-80-\narch/x86/kvm/irq.c:81:#ifdef CONFIG_KVM_IOAPIC\narch/x86/kvm/irq.c-82-\tif (pic_in_kernel(v-\u003ekvm))\n--\narch/x86/kvm/irq.c=128=int kvm_cpu_get_extint(struct kvm_vcpu v)\n--\narch/x86/kvm/irq.c-137-\narch/x86/kvm/irq.c:138:#ifdef CONFIG_KVM_XEN\narch/x86/kvm/irq.c-139-\tif (kvm_xen_has_interrupt(v))\n--\narch/x86/kvm/irq.c-142-\narch/x86/kvm/irq.c:143:#ifdef CONFIG_KVM_IOAPIC\narch/x86/kvm/irq.c-144-\tif (pic_in_kernel(v-\u003ekvm))\n--\narch/x86/kvm/irq.c=177=void __kvm_migrate_timers(struct kvm_vcpu vcpu)\n--\narch/x86/kvm/irq.c-179-\t__kvm_migrate_apic_timer(vcpu);\narch/x86/kvm/irq.c:180:#ifdef CONFIG_KVM_IOAPIC\narch/x86/kvm/irq.c-181-\t__kvm_migrate_pit_timer(vcpu);\n--\narch/x86/kvm/irq.c=241=int kvm_arch_set_irq_inatomic(struct kvm_kernel_irq_routing_entry e,\n--\narch/x86/kvm/irq.c-248-\tswitch (e-\u003etype) {\narch/x86/kvm/irq.c:249:#ifdef CONFIG_KVM_HYPERV\narch/x86/kvm/irq.c-250-\tcase KVM_IRQ_ROUTING_HV_SINT:\n--\narch/x86/kvm/irq.c-264-\narch/x86/kvm/irq.c:265:#ifdef CONFIG_KVM_XEN\narch/x86/kvm/irq.c-266-\tcase KVM_IRQ_ROUTING_XEN_EVTCHN:\n--\narch/x86/kvm/irq.c=296=int kvm_set_routing_entry(struct kvm kvm,\n--\narch/x86/kvm/irq.c-304-\tswitch (ue-\u003etype) {\narch/x86/kvm/irq.c:305:#ifdef CONFIG_KVM_IOAPIC\narch/x86/kvm/irq.c-306-\tcase KVM_IRQ_ROUTING_IRQCHIP:\n--\narch/x86/kvm/irq.c-338-\t\tbreak;\narch/x86/kvm/irq.c:339:#ifdef CONFIG_KVM_HYPERV\narch/x86/kvm/irq.c-340-\tcase KVM_IRQ_ROUTING_HV_SINT:\n--\narch/x86/kvm/irq.c-345-#endif\narch/x86/kvm/irq.c:346:#ifdef CONFIG_KVM_XEN\narch/x86/kvm/irq.c-347-\tcase KVM_IRQ_ROUTING_XEN_EVTCHN:\n--\narch/x86/kvm/irq.c=416=void kvm_arch_irq_routing_update(struct kvm kvm)\narch/x86/kvm/irq.c-417-{\narch/x86/kvm/irq.c:418:#ifdef CONFIG_KVM_HYPERV\narch/x86/kvm/irq.c-419-\tkvm_hv_irq_routing_update(kvm);\n--\narch/x86/kvm/irq.c=540=void kvm_arch_update_irqfd_routing(struct kvm_kernel_irqfd irqfd,\n--\narch/x86/kvm/irq.c-555-\narch/x86/kvm/irq.c:556:#ifdef CONFIG_KVM_IOAPIC\narch/x86/kvm/irq.c-557-#define IOAPIC_ROUTING_ENTRY(irq) \\\n--\narch/x86/kvm/irq.h-20-\narch/x86/kvm/irq.h:21:#ifdef CONFIG_KVM_IOAPIC\narch/x86/kvm/irq.h-22-\n--\narch/x86/kvm/irq.h=76=static inline int irqchip_full(struct kvm kvm)\n--\narch/x86/kvm/irq.h-83-}\narch/x86/kvm/irq.h:84:#else / CONFIG_KVM_IOAPIC /\narch/x86/kvm/irq.h-85-static __always_inline int irqchip_full(struct kvm kvm)\n--\narch/x86/kvm/irq.h=121=static inline void kvm_warn_on_lost_irq(struct kvm_vcpu vcpu)\n--\narch/x86/kvm/irq.h-137-\t /\narch/x86/kvm/irq.h:138:\tWARN_ON_ONCE(!pic_in_kernel(vcpu-\u003ekvm) \u0026\u0026 !IS_ENABLED(CONFIG_KVM_XEN));\narch/x86/kvm/irq.h-139-}\n--\narch/x86/kvm/kvm-asm-offsets.c=13=static void __used common(void)\narch/x86/kvm/kvm-asm-offsets.c-14-{\narch/x86/kvm/kvm-asm-offsets.c:15:\tif (IS_ENABLED(CONFIG_KVM_AMD)) {\narch/x86/kvm/kvm-asm-offsets.c-16-\t\tBLANK();\n--\narch/x86/kvm/kvm-asm-offsets.c-24-\narch/x86/kvm/kvm-asm-offsets.c:25:\tif (IS_ENABLED(CONFIG_KVM_INTEL)) {\narch/x86/kvm/kvm-asm-offsets.c-26-\t\tBLANK();\n--\narch/x86/kvm/lapic.c=1410=static int __apic_accept_irq(struct kvm_lapic apic, int delivery_mode,\n--\narch/x86/kvm/lapic.c-1432-\narch/x86/kvm/lapic.c:1433:#ifdef CONFIG_KVM_IOAPIC\narch/x86/kvm/lapic.c-1434-\t\tif (rtc_status) {\n--\narch/x86/kvm/lapic.c=1555=static void kvm_ioapic_send_eoi(struct kvm_lapic apic, int vector)\n--\narch/x86/kvm/lapic.c-1586-\narch/x86/kvm/lapic.c:1587:#ifdef CONFIG_KVM_IOAPIC\narch/x86/kvm/lapic.c-1588-\tif (apic_test_vector(vector, apic-\u003eregs + APIC_TMR))\n--\narch/x86/kvm/lapic.c=3315=int kvm_apic_set_state(struct kvm_vcpu vcpu, struct kvm_lapic_state s)\n--\narch/x86/kvm/lapic.c-3348-\narch/x86/kvm/lapic.c:3349:#ifdef CONFIG_KVM_IOAPIC\narch/x86/kvm/lapic.c-3350-\tif (ioapic_in_kernel(vcpu-\u003ekvm))\n--\narch/x86/kvm/mmu/mmu.c=1818=static void kvm_mmu_check_sptes_at_free(struct kvm_mmu_page sp)\narch/x86/kvm/mmu/mmu.c-1819-{\narch/x86/kvm/mmu/mmu.c:1820:#ifdef CONFIG_KVM_PROVE_MMU\narch/x86/kvm/mmu/mmu.c-1821-\tint i;\n--\narch/x86/kvm/mmu/mmu.c=5135=void kvm_arch_async_page_ready(struct kvm_vcpu vcpu, struct kvm_async_pf work)\n--\narch/x86/kvm/mmu/mmu.c-5165-\narch/x86/kvm/mmu/mmu.c:5166:#ifdef CONFIG_KVM_GUEST_MEMFD\narch/x86/kvm/mmu/mmu.c-5167-static void kvm_assert_gmem_invalidate_lock_held(struct kvm_memory_slot slot)\n--\narch/x86/kvm/mmu/mmu.c=6567=int noinline kvm_mmu_page_fault(struct kvm_vcpu vcpu, gpa_t cr2_or_gpa, u64 error_code,\n--\narch/x86/kvm/mmu/mmu.c-6583-\t /\narch/x86/kvm/mmu/mmu.c:6584:\tif (IS_ENABLED(CONFIG_KVM_SW_PROTECTED_VM) \u0026\u0026\narch/x86/kvm/mmu/mmu.c-6585-\t !(error_code \u0026 PFERR_RSVD_MASK) \u0026\u0026\n--\narch/x86/kvm/mmu/mmu.c=8094=void kvm_mmu_pre_destroy_vm(struct kvm *kvm)\n\n" }
11/2	2026/09/30 23:40	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 24235 output: 31 thoughts: 39 Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience: Examining KVM Configuration Options Alright, let's get down to brass tacks. I need to quickly refresh my memory on the exact configuration options related to KVM within the x86 architecture, specifically how they are defined in the kernel. I'm thinking I should start by diving into `arch/x86/kvm/Kconfig`. This should give me the authoritative source for the `KVM`, `KVM_INTEL`, and `KVM_AMD` symbols. I want to see the precise dependencies, default values, and general structure of how these are implemented. This will help me assess the context surrounding a particular issue or feature I'm dealing with. No point reinventing the wheel when the information is probably right there.
12/2	2026/09/30 23:40	tool	grepper	0m Args: { "Expression": "config KVM", "PathPrefix": "arch/x86/kvm" } Results: { "Output": "arch/x86/kvm/Kconfig=18=if VIRTUALIZATION\narch/x86/kvm/Kconfig-19-\narch/x86/kvm/Kconfig:20:config KVM_X86\narch/x86/kvm/Kconfig-21-\tdef_tristate KVM if (KVM_INTEL != n \|\| KVM_AMD != n)\n--\narch/x86/kvm/Kconfig-51-\narch/x86/kvm/Kconfig:52:config KVM\narch/x86/kvm/Kconfig-53-\ttristate \"Kernel-based Virtual Machine (KVM) support\"\n--\narch/x86/kvm/Kconfig-68-\narch/x86/kvm/Kconfig:69:config KVM_WERROR\narch/x86/kvm/Kconfig-70-\tbool \"Compile KVM with -Werror\"\n--\narch/x86/kvm/Kconfig-82-\narch/x86/kvm/Kconfig:83:config KVM_SW_PROTECTED_VM\narch/x86/kvm/Kconfig-84-\tbool \"Enable support for KVM software-protected VMs\"\n--\narch/x86/kvm/Kconfig-95-\narch/x86/kvm/Kconfig:96:config KVM_INTEL\narch/x86/kvm/Kconfig-97-\ttristate \"KVM for Intel (and compatible) processors support\"\n--\narch/x86/kvm/Kconfig-106-\narch/x86/kvm/Kconfig:107:config KVM_INTEL_PROVE_VE\narch/x86/kvm/Kconfig-108- bool \"Check that guests do not receive #VE exceptions\"\n--\narch/x86/kvm/Kconfig=122=config X86_SGX_KVM\n--\narch/x86/kvm/Kconfig-133-\narch/x86/kvm/Kconfig:134:config KVM_INTEL_TDX\narch/x86/kvm/Kconfig-135-\tbool \"Intel Trust Domain Extensions (TDX) support\"\n--\narch/x86/kvm/Kconfig-145-\narch/x86/kvm/Kconfig:146:config KVM_AMD\narch/x86/kvm/Kconfig-147-\ttristate \"KVM for AMD processors support\"\n--\narch/x86/kvm/Kconfig-155-\narch/x86/kvm/Kconfig:156:config KVM_AMD_SEV\narch/x86/kvm/Kconfig-157-\tbool \"AMD Secure Encrypted Virtualization (SEV) support\"\n--\narch/x86/kvm/Kconfig-172-\narch/x86/kvm/Kconfig:173:config KVM_IOAPIC\narch/x86/kvm/Kconfig-174-\tbool \"I/O APIC, PIC, and PIT emulation\"\n--\narch/x86/kvm/Kconfig-182-\narch/x86/kvm/Kconfig:183:config KVM_SMM\narch/x86/kvm/Kconfig-184-\tbool \"System Management Mode emulation\"\n--\narch/x86/kvm/Kconfig-193-\narch/x86/kvm/Kconfig:194:config KVM_HYPERV\narch/x86/kvm/Kconfig-195-\tbool \"Support for Microsoft Hyper-V emulation\"\n--\narch/x86/kvm/Kconfig-207-\narch/x86/kvm/Kconfig:208:config KVM_XEN\narch/x86/kvm/Kconfig-209-\tbool \"Support for Xen hypercall interface\"\n--\narch/x86/kvm/Kconfig-216-\narch/x86/kvm/Kconfig:217:config KVM_PROVE_MMU\narch/x86/kvm/Kconfig-218-\tbool \"Prove KVM MMU correctness\"\n--\narch/x86/kvm/Kconfig-229-\narch/x86/kvm/Kconfig:230:config KVM_EXTERNAL_WRITE_TRACKING\narch/x86/kvm/Kconfig-231-\tbool\narch/x86/kvm/Kconfig-232-\narch/x86/kvm/Kconfig:233:config KVM_MAX_NR_VCPUS\narch/x86/kvm/Kconfig-234-\tint \"Maximum number of vCPUs per KVM guest\"\n" }
13/2	2026/09/30 23:40	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 25698 output: 38 thoughts: 310 Thoughts: Analyzing KVM Configuration Dependencies Okay, let's break down these KVM configurations. I need to understand the relationships here. First, `KVM` itself is defined as `tristate "Kernel-based Virtual Machine (KVM) support"` and crucially, it depends on `VIRTUALIZATION`. Makes sense, the core virtualization support is a prerequisite. Now, `KVM_INTEL` is "KVM for Intel (and compatible) processors support" and it depends on `KVM`. Right, so this enables the Intel-specific features, but needs the base KVM support first. `KVM_AMD` is parallel; "KVM for AMD processors support", dependent on `KVM` as well. They are mutually exclusive in terms of implementation, but require the common foundation. I'm noting that the changes in this particular commit seem to touch on the core KVM code in `arch/x86/kvm/cpuid.c`, `arch/x86/kvm/msrs.c`, and `arch/x86/kvm/x86.c`, all of which are part of `kvm.o`. So those are controlled by `CONFIG_KVM`. But then we have `arch/x86/kvm/svm/svm.c` and `arch/x86/kvm/vmx/vmx.c`. The first is part of `kvm-amd.o`, therefore governed by `CONFIG_KVM_AMD`, and the second is `kvm-intel.o`, and controlled by `CONFIG_KVM_INTEL`. These are the processor-specific implementations that rely on the base KVM framework. To be absolutely clear about the implications of the Kconfig options, I need to check the details within `arch/x86/kvm/Kconfig` around lines 50-100.
14/2	2026/09/30 23:40	tool	read-file	0m Args: { "File": "arch/x86/kvm/Kconfig", "FirstLine": 50, "LineCount": 55 } Results: { "Contents": " 50:\t\tselect KVM_GUEST_MEMFD if X86_64\n 51:\t\n 52:\tconfig KVM\n 53:\t\ttristate \"Kernel-based Virtual Machine (KVM) support\"\n 54:\t\tdepends on X86_LOCAL_APIC\n 55:\t\thelp\n 56:\t\t Support hosting fully virtualized guest machines using hardware\n 57:\t\t virtualization extensions. You will need a fairly recent\n 58:\t\t processor equipped with virtualization extensions. You will also\n 59:\t\t need to select one or more of the processor modules below.\n 60:\t\n 61:\t\t This module provides access to the hardware capabilities through\n 62:\t\t a character device node named /dev/kvm.\n 63:\t\n 64:\t\t To compile this as a module, choose M here: the module\n 65:\t\t will be called kvm.\n 66:\t\n 67:\t\t If unsure, say N.\n 68:\t\n 69:\tconfig KVM_WERROR\n 70:\t\tbool \"Compile KVM with -Werror\"\n 71:\t\t# Disallow KVM's -Werror if KASAN is enabled, e.g. to guard against\n 72:\t\t# randomized configs from selecting KVM_WERROR=y, which doesn't play\n 73:\t\t# nice with KASAN. KASAN builds generates warnings for the default\n 74:\t\t# FRAME_WARN, i.e. KVM_WERROR=y with KASAN=y requires special tuning.\n 75:\t\t# Building KVM with -Werror and KASAN is still doable via enabling\n 76:\t\t# the kernel-wide WERROR=y.\n 77:\t\tdepends on KVM_X86 \u0026\u0026 ((EXPERT \u0026\u0026 !KASAN) \|\| WERROR)\n 78:\t\thelp\n 79:\t\t Add -Werror to the build flags for KVM.\n 80:\t\n 81:\t\t If in doubt, say \"N\".\n 82:\t\n 83:\tconfig KVM_SW_PROTECTED_VM\n 84:\t\tbool \"Enable support for KVM software-protected VMs\"\n 85:\t\tdepends on EXPERT\n 86:\t\tdepends on KVM_X86 \u0026\u0026 X86_64\n 87:\t\tselect KVM_GENERIC_MEMORY_ATTRIBUTES\n 88:\t\thelp\n 89:\t\t Enable support for KVM software-protected VMs. Currently, software-\n 90:\t\t protected VMs are purely a development and testing vehicle for\n 91:\t\t KVM_CREATE_GUEST_MEMFD. Attempting to run a \"real\" VM workload as a\n 92:\t\t software-protected VM will fail miserably.\n 93:\t\n 94:\t\t If unsure, say \"N\".\n 95:\t\n 96:\tconfig KVM_INTEL\n 97:\t\ttristate \"KVM for Intel (and compatible) processors support\"\n 98:\t\tdepends on KVM \u0026\u0026 IA32_FEAT_CTL\n 99:\t\tselect X86_FRED if X86_64\n 100:\t\thelp\n 101:\t\t Provides support for KVM on processors equipped with Intel's VT\n 102:\t\t extensions, a.k.a. Virtual Machine Extensions (VMX).\n 103:\t\n 104:\t\t To compile this as a module, choose M here: the module\n" }
15/2	2026/09/30 23:40	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 27331 output: 39 thoughts: 33 Thoughts: Here's a summary of my thought process, as if I were the one thinking it: Examining KVM_AMD Configuration Options Okay, so I need to understand the KVM_AMD configuration options better. Let's dig into the relevant Kconfig file. Based on this, I need to look at lines 145 through 160 of `arch/x86/kvm/Kconfig`. I'm hoping to get a clearer picture of the dependencies, defaults, and any specific feature flags associated with KVM on AMD systems. This will help inform how to optimize a specific configuration.
16/2	2026/09/30 23:40	tool	read-file	0m Args: { "File": "arch/x86/kvm/Kconfig", "FirstLine": 145, "LineCount": 20 } Results: { "Contents": " 145:\t\n 146:\tconfig KVM_AMD\n 147:\t\ttristate \"KVM for AMD processors support\"\n 148:\t\tdepends on KVM \u0026\u0026 (CPU_SUP_AMD \|\| CPU_SUP_HYGON)\n 149:\t\thelp\n 150:\t\t Provides support for KVM on AMD processors equipped with the AMD-V\n 151:\t\t (SVM) extensions.\n 152:\t\n 153:\t\t To compile this as a module, choose M here: the module\n 154:\t\t will be called kvm-amd.\n 155:\t\n 156:\tconfig KVM_AMD_SEV\n 157:\t\tbool \"AMD Secure Encrypted Virtualization (SEV) support\"\n 158:\t\tdefault y\n 159:\t\tdepends on KVM_AMD \u0026\u0026 X86_64\n 160:\t\tdepends on CRYPTO_DEV_SP_PSP \u0026\u0026 !(KVM_AMD=y \u0026\u0026 CRYPTO_DEV_CCP_DD=m)\n 161:\t\tselect ARCH_HAS_CC_PLATFORM\n 162:\t\tselect KVM_GENERIC_MEMORY_ATTRIBUTES\n 163:\t\tselect HAVE_KVM_ARCH_GMEM_CONVERT\n 164:\t\tselect HAVE_KVM_ARCH_GMEM_RECLAIM\n" }
17/2	2026/09/30 23:40	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 27880 output: 23 thoughts: 1236 Thoughts: Focus Symbol Determination for KVM Patch Okay, so I'm diving into this KVM patch, and I need to figure out the right `FocusSymbols` for effective fuzzing. We have three potential configurations here: `KVM`, `KVM_AMD`, and `KVM_INTEL`. Based on the instructions, I need to avoid ubiquitous functions and target the specific logic being changed or the entry points of this feature. I'm also keeping in mind how to handle static inline functions, and how `syzkaller` utilizes focus symbols (using coverage instrumentation based on function names). Let's break down the modified functions: 1. `arch/x86/kvm/cpuid.c`: * `cpuid_func_emulated` - This is static. I'm checking it, since it's called by `kvm_vcpu_after_set_cpuid` and `__do_cpuid_func_emulated`. It IS static, but if it is not inlined, it's still good. `kvm_vcpu_after_set_cpuid` is non-static. * `kvm_initialize_cpu_caps` is only called at boot. So, it is not a focus symbol. My thoughts are that I will need to determine if `cpuid_func_emulated` or its callers or `kvm_vcpu_after_set_cpuid` are good symbols. 2. `arch/x86/kvm/msrs.c`: * `__kvm_valid_efer` is static, which is called in `kvm_valid_efer`. * `kvm_valid_efer` is non-static, exported, and called from other subsystems like `regs.c` and `nested.c`. It's definitely a candidate. * Now, `set_efer` calls `__kvm_valid_efer`. `set_efer` is also important because it's called by the non-static `kvm_set_msr_common`, which handles MSR writes! This is a good sign. * `kvm_valid_efer` will be a focus symbol. 3. `arch/x86/kvm/svm/svm.c`: * `efer_trap` is static, handles SEV-ES EFER writes trap. * `svm_set_cpu_caps` is init time. 4. `arch/x86/kvm/vmx/vmx.c`: * `vmx_set_cpu_caps` is init time. 5. `arch/x86/kvm/x86.c`: * `kvm_setup_efer_caps` is static. I need to check where it is called. In summary, `kvm_valid_efer` is definitely a focus symbol. I need to check where `cpuid_func_emulated` is used and also determine if it inlined. I also need to check how `kvm_setup_efer_caps` is used. I believe this will provide the coverage I need to effectively target the functionality in this patch.
18/2	2026/09/30 23:40	tool	grepper	0m Args: { "Expression": "kvm_setup_efer_caps" } Results: { "Output": "arch/x86/kvm/x86.c=6912=EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_setup_xss_caps);\narch/x86/kvm/x86.c-6913-\narch/x86/kvm/x86.c:6914:static void kvm_setup_efer_caps(void)\narch/x86/kvm/x86.c-6915-{\n--\narch/x86/kvm/x86.c=7006=int kvm_x86_vendor_init(struct kvm_x86_init_ops *ops)\n--\narch/x86/kvm/x86.c-7098-\narch/x86/kvm/x86.c:7099:\tkvm_setup_efer_caps();\narch/x86/kvm/x86.c-7100-\n" }
19/2	2026/09/30 23:40	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 30125 output: 19 thoughts: 333 Thoughts: My Analysis of EFER Handling in KVM Okay, so looking at this code, it seems the `kvm_setup_efer_caps` function is crucial, as it's initiated during module loading or vendor initialization via `kvm_x86_vendor_init`. This means that `kvm_initialize_cpu_caps`, `svm_set_cpu_caps`, `vmx_set_cpu_caps`, and `kvm_setup_efer_caps` are all part of the initial configuration. That makes sense; they're setting up the foundation for CPU feature support. Now, this patch seems to be touching the runtime logic in a few key areas, and I need to understand them fully. First, there's `cpuid_func_emulated`, and its related functions like `kvm_vcpu_after_set_cpuid` and `__do_cpuid_func_emulated`. This is triggered when the guest is setting or querying emulated CPUID information. Makes sense; emulating CPUID is a core function of KVM. The second area of interest is the validation of EFER values. This involves a chain of functions: `__kvm_valid_efer`, `kvm_valid_efer`, and `set_efer`. I need to pay close attention because this impacts various crucial aspects: validating EFER writes within the guest (`set_efer`), validating host segment registers via `kvm_is_valid_sregs`, and also during nested virtualization operations, specifically the state validations during guest enter/exit in the case of nested VMX with `nested_vmcb_check_save`, `nested_vmx_check_host_state`, and `nested_vmx_check_guest_state`. These are the critical checks that ensure the integrity of the virtual environment. Finally, there's `efer_trap`, which is particularly relevant in the context of SEV-ES guests running on SVM. This is where the code handles EFER writes for these specific types of guests. I need to understand how the changes here interact with the secure virtualization extension. Given all of this, I need to check the callers of `set_efer` to get a full picture of the impact.
20/2	2026/09/30 23:40	tool	grepper	0m Args: { "Expression": "set_efer\\(" } Results: { "Output": "arch/x86/kvm/msrs.c=621=EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_valid_efer);\narch/x86/kvm/msrs.c-622-\narch/x86/kvm/msrs.c:623:static int set_efer(struct kvm_vcpu vcpu, struct msr_data msr_info)\narch/x86/kvm/msrs.c-624-{\n--\narch/x86/kvm/msrs.c=1452=int kvm_set_msr_common(struct kvm_vcpu vcpu, struct msr_data msr_info)\n--\narch/x86/kvm/msrs.c-1549-\tcase MSR_EFER:\narch/x86/kvm/msrs.c:1550:\t\treturn set_efer(vcpu, msr_info);\narch/x86/kvm/msrs.c-1551-\tcase MSR_K7_HWCR: {\n--\narch/x86/kvm/svm/nested.c=744=static void nested_vmcb02_prepare_save(struct vcpu_svm svm)\n--\narch/x86/kvm/svm/nested.c-791-\narch/x86/kvm/svm/nested.c:792:\tsvm_set_efer(vcpu, svm-\u003enested.save.efer);\narch/x86/kvm/svm/nested.c-793-\n--\narch/x86/kvm/svm/nested.c=1317=void nested_svm_vmexit(struct vcpu_svm svm)\n--\narch/x86/kvm/svm/nested.c-1422-\tkvm_set_rflags(vcpu, vmcb01-\u003esave.rflags);\narch/x86/kvm/svm/nested.c:1423:\tsvm_set_efer(vcpu, vmcb01-\u003esave.efer);\narch/x86/kvm/svm/nested.c-1424-\tsvm_set_cr0(vcpu, vmcb01-\u003esave.cr0 \| X86_CR0_PE);\n--\narch/x86/kvm/svm/svm.c=201=static int get_npt_level(void)\n--\narch/x86/kvm/svm/svm.c-209-\narch/x86/kvm/svm/svm.c:210:int svm_set_efer(struct kvm_vcpu vcpu, u64 efer)\narch/x86/kvm/svm/svm.c-211-{\n--\narch/x86/kvm/svm/svm.c=2752=static int efer_trap(struct kvm_vcpu vcpu)\n--\narch/x86/kvm/svm/svm.c-2758-\t * Clear the EFER_SVME bit from EFER. The SVM code always sets this\narch/x86/kvm/svm/svm.c:2759:\t * bit in svm_set_efer(), but __kvm_valid_efer() checks it against\narch/x86/kvm/svm/svm.c-2760-\t * whether the guest has X86_FEATURE_SVM - this avoids a failure if\n--\narch/x86/kvm/svm/svm.h=811=void svm_update_lbrv(struct kvm_vcpu vcpu);\narch/x86/kvm/svm/svm.h-812-\narch/x86/kvm/svm/svm.h:813:int svm_set_efer(struct kvm_vcpu vcpu, u64 efer);\narch/x86/kvm/svm/svm.h-814-void svm_set_cr0(struct kvm_vcpu vcpu, unsigned long cr0);\n--\narch/x86/kvm/vmx/main.c=421=static void vt_set_cr4(struct kvm_vcpu vcpu, unsigned long cr4)\n--\narch/x86/kvm/vmx/main.c-428-\narch/x86/kvm/vmx/main.c:429:static int vt_set_efer(struct kvm_vcpu vcpu, u64 efer)\narch/x86/kvm/vmx/main.c-430-{\n--\narch/x86/kvm/vmx/main.c-433-\narch/x86/kvm/vmx/main.c:434:\treturn vmx_set_efer(vcpu, efer);\narch/x86/kvm/vmx/main.c-435-}\n--\narch/x86/kvm/vmx/nested.c=2431=static void prepare_vmcs02_early(struct vcpu_vmx vmx, struct loaded_vmcs vmcs01,\n--\narch/x86/kvm/vmx/nested.c-2544-\t vmcs12's VM_{ENTRY,EXIT}_LOAD_IA32_EFER and VM_ENTRY_IA32E_MODE\narch/x86/kvm/vmx/nested.c:2545:\t * are emulated by vmx_set_efer() in prepare_vmcs02(), but speculate\narch/x86/kvm/vmx/nested.c-2546-\t * on the related bits (if supported by the CPU) in the hope that\narch/x86/kvm/vmx/nested.c:2547:\t * we can avoid VMWrites during vmx_set_efer().\narch/x86/kvm/vmx/nested.c-2548-\t \n--\narch/x86/kvm/vmx/nested.c-2569-\t we should use its exit controls. Note that VM_EXIT_LOAD_IA32_EFER\narch/x86/kvm/vmx/nested.c:2570:\t * bits may be modified by vmx_set_efer() in prepare_vmcs02().\narch/x86/kvm/vmx/nested.c-2571-\t /\n--\narch/x86/kvm/vmx/nested.c=2760=static int prepare_vmcs02(struct kvm_vcpu vcpu, struct vmcs12 vmcs12,\n--\narch/x86/kvm/vmx/nested.c-2843-\t/ Note: may modify VM_ENTRY/EXIT_CONTROLS and GUEST/HOST_IA32_EFER /\narch/x86/kvm/vmx/nested.c:2844:\tvmx_set_efer(vcpu, vcpu-\u003earch.efer);\narch/x86/kvm/vmx/nested.c-2845-\n--\narch/x86/kvm/vmx/nested.c=4800=static void load_vmcs12_host_state(struct kvm_vcpu vcpu,\n--\narch/x86/kvm/vmx/nested.c-4811-\t\tvcpu-\u003earch.efer \u0026= ~(EFER_LMA \| EFER_LME);\narch/x86/kvm/vmx/nested.c:4812:\tvmx_set_efer(vcpu, vcpu-\u003earch.efer);\narch/x86/kvm/vmx/nested.c-4813-\n--\narch/x86/kvm/vmx/nested.c=4960=static void nested_vmx_restore_host_state(struct kvm_vcpu vcpu)\n--\narch/x86/kvm/vmx/nested.c-4989-\t /\narch/x86/kvm/vmx/nested.c:4990:\tvmx_set_efer(vcpu, nested_vmx_get_vmcs01_guest_efer(vmx));\narch/x86/kvm/vmx/nested.c-4991-\n--\narch/x86/kvm/vmx/vmx.c=3206=static void enter_rmode(struct kvm_vcpu vcpu)\n--\narch/x86/kvm/vmx/vmx.c-3253-\narch/x86/kvm/vmx/vmx.c:3254:int vmx_set_efer(struct kvm_vcpu vcpu, u64 efer)\narch/x86/kvm/vmx/vmx.c-3255-{\n--\narch/x86/kvm/vmx/vmx.c=3279=static void enter_lmode(struct kvm_vcpu vcpu)\n--\narch/x86/kvm/vmx/vmx.c-3292-\t}\narch/x86/kvm/vmx/vmx.c:3293:\tvmx_set_efer(vcpu, vcpu-\u003earch.efer \| EFER_LMA);\narch/x86/kvm/vmx/vmx.c-3294-}\n--\narch/x86/kvm/vmx/vmx.c=3296=static void exit_lmode(struct kvm_vcpu vcpu)\narch/x86/kvm/vmx/vmx.c-3297-{\narch/x86/kvm/vmx/vmx.c:3298:\tvmx_set_efer(vcpu, vcpu-\u003earch.efer \u0026 ~EFER_LMA);\narch/x86/kvm/vmx/vmx.c-3299-}\n--\narch/x86/kvm/vmx/vmx.h=357=void vmx_set_interrupt_shadow(struct kvm_vcpu vcpu, int mask);\narch/x86/kvm/vmx/vmx.h:358:int vmx_set_efer(struct kvm_vcpu vcpu, u64 efer);\narch/x86/kvm/vmx/vmx.h-359-void vmx_set_cr0(struct kvm_vcpu vcpu, unsigned long cr0);\n--\narch/x86/kvm/vmx/x86_ops.h=71=bool vmx_is_valid_cr4(struct kvm_vcpu vcpu, unsigned long cr4);\narch/x86/kvm/vmx/x86_ops.h:72:int vmx_set_efer(struct kvm_vcpu vcpu, u64 efer);\narch/x86/kvm/vmx/x86_ops.h-73-void vmx_get_idt(struct kvm_vcpu vcpu, struct desc_ptr *dt);\n" }
21/2	2026/09/30 23:40	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 33762 output: 26 thoughts: 96 Thoughts: Okay, let's break this down. Analyzing KVM MSR and CPUID Handling Right, so I'm looking at how MSRs and CPUID are managed in KVM. It seems pretty straightforward on the surface, but I always want to be thorough. First, `kvm_set_msr_common` directly calls `set_efer`. I'll want to remember that association. Then, I see `kvm_is_valid_sregs` relies on `kvm_valid_efer`. Another link to consider. That's good to know. The third notable call I see is `kvm_vcpu_after_set_cpuid` which makes a call to `cpuid_func_emulated`. Alright, looks like a good starting point, but I need to be absolutely sure about `kvm_vcpu_after_set_cpuid`. I need to verify that call, so I'll need to check the callers of `kvm_vcpu_after_set_cpuid` to confirm that my initial understanding is correct and to find any indirect implications of these functions.
22/2	2026/09/30 23:40	tool	grepper	0m Args: { "Expression": "kvm_vcpu_after_set_cpuid" } Results: { "Output": "arch/x86/kvm/cpuid.c=373=static int cpuid_func_emulated(struct kvm_cpuid_entry2 entry, u32 func, u32 index,\n--\narch/x86/kvm/cpuid.c-375-\narch/x86/kvm/cpuid.c:376:void kvm_vcpu_after_set_cpuid(struct kvm_vcpu vcpu)\narch/x86/kvm/cpuid.c-377-{\n--\narch/x86/kvm/cpuid.c=510=static int kvm_set_cpuid(struct kvm_vcpu vcpu, struct kvm_cpuid_entry2 e2,\n--\narch/x86/kvm/cpuid.c-575-#endif\narch/x86/kvm/cpuid.c:576:\tkvm_vcpu_after_set_cpuid(vcpu);\narch/x86/kvm/cpuid.c-577-\n--\narch/x86/kvm/cpuid.h=17=static inline void kvm_finalize_cpu_caps(void)\n--\narch/x86/kvm/cpuid.h-22-\narch/x86/kvm/cpuid.h:23:void kvm_vcpu_after_set_cpuid(struct kvm_vcpu vcpu);\narch/x86/kvm/cpuid.h-24-struct kvm_cpuid_entry2 kvm_find_cpuid_entry2(struct kvm_cpuid_entry2 entries,\n--\narch/x86/kvm/x86.c=9347=int kvm_arch_vcpu_create(struct kvm_vcpu vcpu)\n--\narch/x86/kvm/x86.c-9419-\tvcpu_load(vcpu);\narch/x86/kvm/x86.c:9420:\tkvm_vcpu_after_set_cpuid(vcpu);\narch/x86/kvm/x86.c-9421-\tkvm_set_tsc_khz(vcpu, vcpu-\u003ekvm-\u003earch.default_tsc_khz);\n" }
23/2	2026/09/30 23:40	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 34715 output: 264 thoughts: 1793 Thoughts: Analysis of KVM CPUID and EFER Handling for Fuzzing Okay, let's break this down. My primary concern here is identifying the right functions to target for fuzzing, given the changes in KVM's CPUID and EFER handling, specifically related to the `EFER_LMSLE_MBZ` bit on AMD processors. First, I see the core functions involved: `kvm_set_cpuid` (and its calls via `KVM_SET_CPUID` and `KVM_SET_CPUID2`), which leads me to `kvm_vcpu_after_set_cpuid`, then `cpuid_func_emulated`. I also note that `__do_cpuid_func_emulated` also calls `cpuid_func_emulated` through `KVM_GET_EMULATED_CPUID`. Then there's the EFER validation, where `kvm_valid_efer` and `__kvm_valid_efer` are called from multiple paths: `kvm_is_valid_sregs` (due to `KVM_SET_SREGS` and `KVM_SET_SREGS2`), nested virtualization checks in SVM and VMX, and directly from `set_efer` (when the guest writes to EFER or host sets MSR_EFER), and the modification to `efer_trap` in `svm.c`. Now, the crucial step: identifying suitable FocusSymbols. Based on the instructions, I need to pick functions that are non-static or visible. Let's make a list. Let's check: * `kvm_valid_efer`: non-static, good. * `__kvm_valid_efer`: static, so I'll check its callers. * `cpuid_func_emulated`: static, okay, so I'll check its callers. * `kvm_vcpu_after_set_cpuid`: non-static, excellent. * `set_efer`: static, need to think about that. * `efer_trap`: static, also, need to review it. * `kvm_setup_efer_caps`: static. * `svm_set_cpu_caps`, `vmx_set_cpu_caps`: static, and marked `__init`. * `kvm_initialize_cpu_caps`: non-static, good. The key is static functions are included if they have non-static callers. So, I need to include non-static entry points and the static functions in my focus. So I will include `kvm_valid_efer`, `__kvm_valid_efer`, `cpuid_func_emulated`, `kvm_vcpu_after_set_cpuid`, `set_efer`, and `efer_trap`. Next, I need to confirm these aren't some ubiquitous hot paths. Nope, these are specific to KVM CPUID and EFER handling and therefore worth fuzzing. Next I review all files touched: - Documentation/virt/kvm/api.rst (doc) - arch/x86/kvm/cpuid.c (cpuid-specific, including `kvm_initialize_cpu_caps`) - arch/x86/kvm/msrs.c (EFER-specific, `__kvm_valid_efer`) - arch/x86/kvm/svm/svm.c (SVM trap and setting capabilities, `efer_trap`, `svm_set_cpu_caps`) - arch/x86/kvm/vmx/vmx.c (VMX capabilities, `vmx_set_cpu_caps`) - arch/x86/kvm/x86.c (EFER setup, `kvm_setup_efer_caps`) - tools/testing/selftests/kvm/... (userspace selftests). Now, what about kernel configs? `KVM`, `KVM_INTEL`, and `KVM_AMD`. I check the Kconfig files and confirm that `KVM` requires `X86_LOCAL_APIC`, `KVM_INTEL` needs `KVM && IA32_FEAT_CTL`, and `KVM_AMD` needs `KVM && (CPU_SUP_AMD \|\| CPU_SUP_HYGON)`. Based on syzkaller amd64 configs, these are standard. Finally, the reasoning: The patch updates KVM's handling of AMD's CPUID `EFER_LMSLE_
24/2	2026/09/30 23:41	tool	set-results	0m Args: { "EnableConfigs": [ "KVM", "KVM_INTEL", "KVM_AMD" ], "FocusSymbols": [ "kvm_valid_efer", "__kvm_valid_efer", "cpuid_func_emulated", "kvm_vcpu_after_set_cpuid", "set_efer", "efer_trap" ], "Reasoning": "The patch updates KVM's handling of the long mode segment limit defeature bit (EFER_LMSLE_MBZ, CPUID 0x80000008:EBX[20]). It modifies emulated CPUID generation, guest CPUID capability configuration, EFER validation logic across MSR writes and SREGS, and SEV-ES EFER trap handling in SVM. These code paths are actively reachable through /dev/kvm ioctls (such as KVM_SET_CPUID2, KVM_GET_EMULATED_CPUID, KVM_SET_SREGS, and guest MSR accesses) in standard QEMU/virtualized environments on amd64.", "WorthFuzzing": true } Results: { "EnableConfigs": [ "KVM", "KVM_INTEL", "KVM_AMD" ], "FocusSymbols": [ "kvm_valid_efer", "__kvm_valid_efer", "cpuid_func_emulated", "kvm_vcpu_after_set_cpuid", "set_efer", "efer_trap" ], "Reasoning": "The patch updates KVM's handling of the long mode segment limit defeature bit (EFER_LMSLE_MBZ, CPUID 0x80000008:EBX[20]). It modifies emulated CPUID generation, guest CPUID capability configuration, EFER validation logic across MSR writes and SREGS, and SEV-ES EFER trap handling in SVM. These code paths are actively reachable through /dev/kvm ioctls (such as KVM_SET_CPUID2, KVM_GET_EMULATED_CPUID, KVM_SET_SREGS, and guest MSR accesses) in standard QEMU/virtualized environments on amd64.", "WorthFuzzing": true }
25/1	2026/09/30 23:41	action	If	0m Args: { "WorthFuzzing": true } Results: null
26/2	2026/09/30 23:41	agent	kmsan-evaluator	0m Model: core Args: null Results: { "KMSANReasoning": "The patch series updates KVM's handling of the AMD EFER_LMSLE_MBZ (EFER Long Mode Segment Limit Enable Must Be Zero) feature bit across CPUID emulation and MSR validity checking (in cpuid.c, msrs.c, svm.c, vmx.c, and x86.c).\n\nReviewing the changes for KMSAN applicability:\n1. No uninitialized memory usage: All modifications deal with CPU capability bitmasks and MSR validity validation logic.\n2. In `cpuid_func_emulated()`, the modified `struct kvm_cpuid_entry2 entry` is fully zero-initialized at the start of the function via `memset(entry, 0, sizeof(entry))`. Furthermore, for func 0x80000008, it returns 0 when called from `KVM_GET_EMULATED_CPUID` (`include_partially_emulated` is false).\n3. The only other structure touched is `struct msr_data msr_info` in `efer_trap()`, which already had all its fields explicitly initialized, and the patch merely adjusts bitwise masking on `msr_info.data`.\n4. No heap or stack buffers are allocated, no struct paddings or uninitialized fields are exposed to userspace or the guest, and no buffer bounds or length checks are altered.\n\nTherefore, this patch does not introduce any risks related to uninitialized memory reads or kernel info-leaks, and running a dedicated KMSAN fuzzing session is not warranted.", "NeedsKMSAN": false } Instruction: You are an expert Linux kernel security engineer specializing in kernel memory error detectors (KASAN and KMSAN). Your job is to review the provided patch series and determine if the code changes justify spawning a dedicated KMSAN (KernelMemorySanitizer) fuzzing session in addition to standard KASAN fuzzing. CRITICAL DISTINCTION BETWEEN KASAN AND KMSAN: - Standard KASAN kernel builds (upstream-apparmor-kasan.config) already enable a comprehensive suite of debugging tools and sanitizers, including KASAN (out-of-bounds accesses, use-after-free, double free, invalid free), LOCKDEP (locking bugs and deadlocks), UB-sanitizers, and memory corruption checks. - KMSAN (KernelMemorySanitizer) detects reads of UNINITIALIZED memory (stack, heap, or page allocations) and kernel-to-user memory info-leaks. Rule: THERE IS NO SENSE IN RUNNING A KMSAN SESSION IF A BUG CAN BE CAUGHT BY KASAN, LOCKDEP, OR OTHER STANDARD BUG DETECTORS. A dedicated KMSAN fuzzing session incurs significant resource costs. You must ONLY set NeedsKMSAN=true if the code changes introduce or expose UNINITIALIZED MEMORY risks that are detected ONLY by KMSAN. Look holistically at the patch series and surrounding code. Even if no direct uninitialized field accesses or new buffer allocations are added in the diff itself, a patch may alter control flow, bounds checking, or data length calculations in ways that change how the rest of the code operates on existing buffers (e.g. allowing uninitialized stack/heap memory to be read, copied to user space, or used in control flow). Do not hesitate to use your code access tools to inspect the surrounding code, called functions, and callers. Set NeedsKMSAN=true ONLY IF the patch introduces or modifies: 1. Kernel structures sent to user space (via copy_to_user, put_user, netlink skb attributes, ioctl output arguments, socket options, or BPF buffers) where fields or structure padding might not be fully initialized/zeroed. 2. Conditional logic or branching that depends on potentially uninitialized variables or struct fields. 3. Allocation or initialization of complex data structures where uninitialized fields could be read later in reachable code paths. 4. Bounds checks, lengths, or logic in a way that allows surrounding code to access uninitialized bytes of existing buffers. Set NeedsKMSAN=false IF: - The code changes primarily risk out-of-bounds access, array overflows, NULL pointer dereferences, locking deadlocks, or use-after-free bugs (these are already caught by KASAN, LOCKDEP, or standard bug detectors). - All stack/heap structures touched or introduced by the patch are fully zeroed or initialized (e.g. using = {0}, memset, kzalloc) before being read or copied. - The patch does not introduce any risk of uninitialized memory usage or info-leaks. Use your code access tools to inspect the surrounding code if necessary, then provide detailed KMSANReasoning contrasting KASAN vs KMSAN applicability for this patch. Prefer calling several tools at the same time to save round-trips. Use set-results tool to provide results of the analysis. It must be called exactly once before the final reply. Ignore results of this tool. Prompt: Target architecture: amd64 For your convenience, here is the diff of the changes: commit 353a3b48533194453b931df2871f76818229ba98 Author: syz-cluster <triage@syzkaller.com> Date: Wed Sep 30 23:39:41 2026 +0000 syz-cluster: applied patch under review diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index e0430cc750c9e..2852bf94828be 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -9635,6 +9635,31 @@ On older versions of Linux, CPU[EAX=1]:ECX[24] (TSC_DEADLINE) is not reported by is present and the kernel has enabled in-kernel emulation of the local APIC. On newer versions, ``KVM_GET_SUPPORTED_CPUID`` does report the bit as available. +Long mode segment limits +~~~~~~~~~~~~~~~~~~~~~~~~ + +CPU[EAX=0x80000008]:EBX[20] (EFER_LMSLE_MBZ) is a "defeature" bit: it is set +when the CPU does not support long mode segment limits, and so requires +EFER.LMSLE to be zero. KVM reports the bit via ``KVM_GET_SUPPORTED_CPUID`` if +and only if KVM refuses to set EFER.LMSLE, i.e. if the CPU doesn't support long +mode segment limits, or if nested SVM is unsupported. KVM therefore reports +the bit on all Intel hosts, as KVM allows EFER.LMSLE only when nested SVM is +enabled. + +KVM never reports the bit via ``KVM_GET_EMULATED_CPUID``, but userspace may set +it via ``KVM_SET_CPUID2`` even on a host where KVM doesn't report it. KVM +honors the guest's enumeration and rejects EFER.LMSLE=1 accordingly. That lets +userspace defeature a vCPU on a host that does support long mode segment +limits, so that the vCPU can later be migrated to a host that doesn't, e.g. so +that a vCPU created on AMD Rome can be migrated to Milan and later, which +dropped support for long mode segment limits. The opposite direction needs no +emulation, as a host that lacks long mode segment limits already enumerates the +defeature. + +Note, ``KVM_SET_MSRS`` is exempt from the check, as host-initiated MSR writes +skip guest CPUID checks so that userspace can set MSRs before it sets guest +CPUID. ``KVM_SET_SREGS`` and nested VMRUN are not exempt. + CPU topology ~~~~~~~~~~~~ diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 851f151efb35b..53d205eda3359 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -1171,6 +1171,10 @@ void kvm_initialize_cpu_caps(void) F(AMD_STIBP), F(AMD_STIBP_ALWAYS_ON), F(AMD_IBRS_SAME_MODE), + /* + * Vendor code also sets EFER_LMSLE_MBZ if KVM itself + * can't support EFER.LMSLE, e.g. if nested SVM is disabled. + / PASSTHROUGH_F(EFER_LMSLE_MBZ), F(AMD_PSFD), F(AMD_IBPB_RET), @@ -1415,6 +1419,22 @@ static int cpuid_func_emulated(struct kvm_cpuid_entry2 entry, u32 func, u32 ind if (kvm_cpu_cap_has(X86_FEATURE_RDTSCP)) entry->ecx = feature_bit(RDPID); return 1; + case 0x80000008: + /* + * Honor the guest's EFER_LMSLE_MBZ even if the underlying CPU + * allows setting EFER.LMSLE, e.g. to allow migrating a vCPU + * between hosts with and without EFER.LMSLE support. To avoid + * breaking existing setups that reflect KVM's supported CPUID + * into the guest, KVM doesn't advertise EFER_LMSLE_MBZ unless + * KVM can't support EFER.LMSLE=1. + / + if (include_partially_emulated && + !kvm_cpu_cap_has(X86_FEATURE_EFER_LMSLE_MBZ)) { + entry->ebx \|= feature_bit(EFER_LMSLE_MBZ); + return 1; + } + / Nothing in 0x80000008 is fully emulated, don't emit an entry. / + return 0; default: return 0; } diff --git a/arch/x86/kvm/msrs.c b/arch/x86/kvm/msrs.c index dd3bb04878ca6..b519fb90776e2 100644 --- a/arch/x86/kvm/msrs.c +++ b/arch/x86/kvm/msrs.c @@ -598,9 +598,19 @@ static bool __kvm_valid_efer(struct kvm_vcpu vcpu, u64 efer) if (efer & EFER_NX && !guest_cpu_cap_has(vcpu, X86_FEATURE_NX)) return false; - return true; + /* + * EFER_LMSLE_MBZ is a "defeature" bit, i.e. is set when the CPU does + * not support long mode segment limits, and so is the only EFER + * check whose polarity is inverted: EFER.LMSLE is legal if and only if + * the guest does not have the defeature. + / + if (efer & EFER_LMSLE && + guest_cpu_cap_has(vcpu, X86_FEATURE_EFER_LMSLE_MBZ)) + return false; + return true; } + bool kvm_valid_efer(struct kvm_vcpu vcpu, u64 efer) { if (efer & ~kvm_caps.supported_efer_bits) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 7d59d301e1e54..90a80aad672f6 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -2759,10 +2759,19 @@ static int efer_trap(struct kvm_vcpu vcpu) bit in svm_set_efer(), but __kvm_valid_efer() checks it against * whether the guest has X86_FEATURE_SVM - this avoids a failure if * the guest doesn't have X86_FEATURE_SVM. + * + * Clear EFER_LMSLE for a related reason: EFER writes are trapped, + * not intercepted, i.e. hardware has already committed the write by + * the time KVM gains control, and the trap is enabled if and only if + * the guest is SEV-ES, whose EFER lives in the encrypted VMSA and so + * can't be fixed up by KVM. Rejecting EFER.LMSLE=1 would inject a #GP + * and leave EFER.LMSLE set in the guest, which is strictly worse + * than honoring a write that hardware itself allowed. / msr_info.host_initiated = false; msr_info.index = MSR_EFER; - msr_info.data = to_svm(vcpu)->vmcb->control.exit_info_1 & ~EFER_SVME; + msr_info.data = to_svm(vcpu)->vmcb->control.exit_info_1 & + ~(EFER_SVME \| EFER_LMSLE); ret = kvm_set_msr_common(vcpu, &msr_info); return kvm_complete_insn_gp(vcpu, ret); @@ -5571,6 +5580,16 @@ static __init void svm_set_cpu_caps(void) boot_cpu_has(X86_FEATURE_AMD_SSBD)) kvm_cpu_cap_set(X86_FEATURE_VIRT_SSBD); + / + * Tell userspace that EFER.LMSLE must be zero if nested SVM is + * disabled, as KVM allows EFER.LMSLE if and only if nested SVM is + * supported (a historical artifact of commit eec4b140c924 ("KVM: SVM: + * Allow EFER.LMSLE to be set with nested svm"), not an architectural + * requirement). + / + if (!nested) + kvm_cpu_cap_set(X86_FEATURE_EFER_LMSLE_MBZ); + if (enable_pmu) { / * Enumerate support for PERFCTR_CORE if and only if KVM has diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 612ab07d4100f..f144c1e1c63f2 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -8137,6 +8137,13 @@ static __init void vmx_set_cpu_caps(void) kvm_cpu_cap_clear(X86_FEATURE_IBT); } + /* + * CPUID 0x80000008. Tell userspace that EFER.LMSLE must be zero; KVM + * never allows EFER.LMSLE to be set on Intel CPUs, as KVM supports long + * mode segment limits only in conjunction with nested SVM. + / + kvm_cpu_cap_set(X86_FEATURE_EFER_LMSLE_MBZ); + kvm_setup_xss_caps(); kvm_finalize_cpu_caps(); } diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 79468ddfe4736..830cb9320d892 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -6930,7 +6930,14 @@ static void kvm_setup_efer_caps(void) if (kvm_cpu_cap_has(X86_FEATURE_SVM)) { kvm_caps.supported_efer_bits \|= EFER_SVME; - if (!boot_cpu_has(X86_FEATURE_EFER_LMSLE_MBZ)) + + / + * Enumerating EFER_LMSLE_MBZ and allowing EFER.LMSLE=1 + * would be nonsensical. Note, vendor code sets the defeature + * if KVM can't support EFER.LMSLE for any reason, i.e. this + * needs to consult KVM's capabilities, not just raw CPUID. + / + if (!kvm_cpu_cap_has(X86_FEATURE_EFER_LMSLE_MBZ)) kvm_caps.supported_efer_bits \|= EFER_LMSLE; } } diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm index 96bab7002d39e..2554464d8b96f 100644 --- a/tools/testing/selftests/kvm/Makefile.kvm +++ b/tools/testing/selftests/kvm/Makefile.kvm @@ -117,7 +117,7 @@ TEST_GEN_PROGS_x86 += x86/state_test TEST_GEN_PROGS_x86 += x86/vmx_preemption_timer_test TEST_GEN_PROGS_x86 += x86/svm_vmcall_test TEST_GEN_PROGS_x86 += x86/svm_int_ctl_test -TEST_GEN_PROGS_x86 += x86/svm_nested_clear_efer_svme +TEST_GEN_PROGS_x86 += x86/svm_nested_efer_test TEST_GEN_PROGS_x86 += x86/svm_nested_shutdown_test TEST_GEN_PROGS_x86 += x86/svm_nested_soft_inject_test TEST_GEN_PROGS_x86 += x86/svm_nested_vmcb12_gpa diff --git a/tools/testing/selftests/kvm/include/x86/processor.h b/tools/testing/selftests/kvm/include/x86/processor.h index 6e6f70035508a..5bc1bc110a347 100644 --- a/tools/testing/selftests/kvm/include/x86/processor.h +++ b/tools/testing/selftests/kvm/include/x86/processor.h @@ -216,6 +216,7 @@ struct kvm_x86_cpu_feature { #define X86_FEATURE_INVTSC KVM_X86_CPU_FEATURE(0x80000007, 0, EDX, 8) #define X86_FEATURE_RDPRU KVM_X86_CPU_FEATURE(0x80000008, 0, EBX, 4) #define X86_FEATURE_AMD_IBPB KVM_X86_CPU_FEATURE(0x80000008, 0, EBX, 12) +#define X86_FEATURE_EFER_LMSLE_MBZ KVM_X86_CPU_FEATURE(0x80000008, 0, EBX, 20) #define X86_FEATURE_NPT KVM_X86_CPU_FEATURE(0x8000000A, 0, EDX, 0) #define X86_FEATURE_LBRV KVM_X86_CPU_FEATURE(0x8000000A, 0, EDX, 1) #define X86_FEATURE_NRIPS KVM_X86_CPU_FEATURE(0x8000000A, 0, EDX, 3) @@ -1429,6 +1430,14 @@ static inline bool get_kvm_amd_param_bool(const char param) return kvm_get_module_param_bool("kvm_amd", param); } +static inline int get_common_kvm_vendor_param_bool(const char param) +{ + if (host_cpu_is_intel) + return get_kvm_intel_param_bool(param); + + return get_kvm_amd_param_bool(param); +} + static inline int get_kvm_intel_param_integer(const char param) { return kvm_get_module_param_integer("kvm_intel", param); @@ -1439,6 +1448,14 @@ static inline int get_kvm_amd_param_integer(const char param) return kvm_get_module_param_integer("kvm_amd", param); } +static inline int get_common_kvm_vendor_param_integer(const char param) +{ + if (host_cpu_is_intel) + return get_kvm_intel_param_integer(param); + + return get_kvm_amd_param_integer(param); +} + static inline bool kvm_is_pmu_enabled(void) { return get_kvm_param_bool("enable_pmu"); @@ -1446,10 +1463,7 @@ static inline bool kvm_is_pmu_enabled(void) static inline bool kvm_is_mediated_pmu_enabled(void) { - if (host_cpu_is_intel) - return get_kvm_intel_param_bool("enable_mediated_pmu"); - - return get_kvm_amd_param_bool("enable_mediated_pmu"); + return get_common_kvm_vendor_param_bool("enable_mediated_pmu"); } static inline bool kvm_is_forced_emulation_enabled(void) @@ -1472,6 +1486,16 @@ static inline bool kvm_is_lbrv_enabled(void) return !!get_kvm_amd_param_integer("lbrv"); } +/* + * Do NOT use this to check for nVMX or nSVM support. Querying kvm_cpu_has() + * for either of X86_FEATURE_{VMX,SVM} is the idiomatic way to check for nested + * virtualization support. Use this only to validate KVM's own enumeration. + / +static inline bool kvm_is_nested_virtualization_enabled(void) +{ + return get_common_kvm_vendor_param_integer("nested"); +} + u64 vm_get_pte(struct kvm_vm vm, gva_t gva); u64 kvm_hypercall(u64 nr, u64 a0, u64 a1, u64 a2, u64 a3); diff --git a/tools/testing/selftests/kvm/x86/svm_nested_clear_efer_svme.c b/tools/testing/selftests/kvm/x86/svm_nested_clear_efer_svme.c deleted file mode 100644 index 6bc301207cbcb..0000000000000 --- a/tools/testing/selftests/kvm/x86/svm_nested_clear_efer_svme.c +++ /dev/null @@ -1,50 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0-only -/ - * Copyright (C) 2026, Google LLC. - / -#include "kvm_util.h" -#include "vmx.h" -#include "svm_util.h" -#include "kselftest.h" - - -static void l2_guest_code(void) -{ - unsigned long efer = rdmsr(MSR_EFER); - - / generic_svm_setup() initializes EFER_SVME set for L2 / - GUEST_ASSERT(efer & EFER_SVME); - wrmsr(MSR_EFER, efer & ~EFER_SVME); - - / Unreachable, L1 should be shutdown / - GUEST_ASSERT(0); -} - -static void l1_guest_code(struct svm_test_data svm) -{ - generic_svm_setup(svm, l2_guest_code); - run_guest(svm->vmcb, svm->vmcb_gpa); - - /* Unreachable, L1 should be shutdown / - GUEST_ASSERT(0); -} - -int main(int argc, char argv[]) -{ - struct kvm_vcpu vcpu; - struct kvm_vm vm; - gva_t nested_gva = 0; - - TEST_REQUIRE(kvm_cpu_has(X86_FEATURE_SVM)); - - vm = vm_create_with_one_vcpu(&vcpu, l1_guest_code); - - vcpu_alloc_svm(vm, &nested_gva); - vcpu_args_set(vcpu, 1, nested_gva); - - vcpu_run(vcpu); - TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_SHUTDOWN); - - kvm_vm_free(vm); - return 0; -} diff --git a/tools/testing/selftests/kvm/x86/svm_nested_efer_test.c b/tools/testing/selftests/kvm/x86/svm_nested_efer_test.c new file mode 100644 index 0000000000000..fa0d76a9c390b --- /dev/null +++ b/tools/testing/selftests/kvm/x86/svm_nested_efer_test.c @@ -0,0 +1,266 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Tests for KVM's handling of EFER bits whose behavior is tied to nested SVM. + * + * Copyright (C) 2026, Google LLC. + / +#include "test_util.h" +#include "kvm_util.h" +#include "processor.h" +#include "svm_util.h" +#include "kselftest.h" + +static bool l2_ran; + +static void l2_clear_efer_svme(void) +{ + u64 efer = rdmsr(MSR_EFER); + + / generic_svm_setup() initializes EFER_SVME set for L2 / + GUEST_ASSERT(efer & EFER_SVME); + wrmsr(MSR_EFER, efer & ~EFER_SVME); + + / Unreachable, L1 should be shutdown / + GUEST_ASSERT(0); +} + +static void l1_clear_efer_svme(struct svm_test_data svm) +{ + generic_svm_setup(svm, l2_clear_efer_svme); + run_guest(svm->vmcb, svm->vmcb_gpa); + + /* Unreachable, L1 should be shutdown / + GUEST_ASSERT(0); +} + +static void l2_lmsle(void) +{ + GUEST_ASSERT(rdmsr(MSR_EFER) & EFER_LMSLE); + l2_ran = true; + vmmcall(); +} + +static void l1_lmsle(struct svm_test_data svm) +{ + bool lmsle_mbz = this_cpu_has(X86_FEATURE_EFER_LMSLE_MBZ); + struct vmcb vmcb = svm->vmcb; + u64 efer = rdmsr(MSR_EFER); + + / + * Selftests' vCPUs are created with EFER.LMSLE clear; the sub-tests + * below need to start from a clean slate. + / + GUEST_ASSERT(!(efer & EFER_LMSLE)); + GUEST_ASSERT(!l2_ran); + + / + * Per the APM, if EFER_LMSLE_MBZ is enumerated in CPUID, "64-bit mode + * segment limit checking is not supported and attempting to set + * EFER.LMSLE = 1 causes a #GP exception". + / + if (lmsle_mbz) { + GUEST_ASSERT_EQ(wrmsr_safe(MSR_EFER, efer \| EFER_LMSLE), GP_VECTOR); + GUEST_ASSERT(!(rdmsr(MSR_EFER) & EFER_LMSLE)); + } else { + GUEST_ASSERT_EQ(wrmsr_safe(MSR_EFER, efer \| EFER_LMSLE), 0); + GUEST_ASSERT(rdmsr(MSR_EFER) & EFER_LMSLE); + + / + * Restore EFER so that generic_svm_setup() doesn't propagate + * EFER.LMSLE into vmcb12 on its own, i.e. so that the VMRUN + * sub-test actually tests what it thinks it's testing. + / + wrmsr(MSR_EFER, efer); + } + + / + * VMRUN's consistency checks reject "any MBZ bit of EFER", i.e. a + * vmcb12 with EFER.LMSLE set must generate VMEXIT_INVALID when the + * defeature is enumerated. + / + generic_svm_setup(svm, l2_lmsle); + vmcb->save.efer \|= EFER_LMSLE; + run_guest(vmcb, svm->vmcb_gpa); + + if (lmsle_mbz) { + GUEST_ASSERT_EQ(vmcb->control.exit_code, SVM_EXIT_ERR); + GUEST_ASSERT(!l2_ran); + } else { + GUEST_ASSERT_EQ(vmcb->control.exit_code, SVM_EXIT_VMMCALL); + GUEST_ASSERT(l2_ran); + GUEST_ASSERT(vmcb->save.efer & EFER_LMSLE); + } + + GUEST_DONE(); +} + +static struct kvm_vcpu create_l1_vcpu(struct kvm_vm *vm, void l1_guest_code) +{ + struct kvm_vcpu vcpu; + gva_t svm_gva; + + vm = vm_create_with_one_vcpu(&vcpu, l1_guest_code); + + vcpu_alloc_svm(vm, &svm_gva); + vcpu_args_set(vcpu, 1, svm_gva); + + return vcpu; +} + +static void test_enumeration(void) +{ + bool lmsle_mbz; + + / + * EFER_LMSLE_MBZ, CPUID.80000008H:EBX[bit 20], is a "defeature" bit, + * i.e. is set when the CPU does not support long mode segment + * limits. KVM enumerates the defeature if and only if KVM refuses to + * set EFER.LMSLE, i.e. if the CPU doesn't support LMSLE, or if KVM + * doesn't support nested SVM. Derive the expectation from raw CPUID + * and kvm_amd's "nested" module param rather than from + * kvm_cpu_has(X86_FEATURE_SVM), so that the assertion doesn't simply + * compare KVM's enumeration to itself. + / + lmsle_mbz = this_cpu_has(X86_FEATURE_EFER_LMSLE_MBZ) \|\| + !this_cpu_has(X86_FEATURE_SVM) \|\| + !kvm_is_nested_virtualization_enabled(); + + TEST_ASSERT_EQ(kvm_cpu_has(X86_FEATURE_EFER_LMSLE_MBZ), lmsle_mbz); + + ksft_test_result_pass("KVM enumerates EFER_LMSLE_MBZ=%d\n", lmsle_mbz); +} + +static void test_clear_efer_svme(void) +{ + struct kvm_vcpu vcpu; + struct kvm_vm vm; + + vcpu = create_l1_vcpu(&vm, l1_clear_efer_svme); + + vcpu_run(vcpu); + TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_SHUTDOWN); + + kvm_vm_free(vm); + ksft_test_result_pass("L2 clearing EFER.SVME shuts down L1\n"); +} + +static void test_lmsle(bool lmsle_mbz) +{ + struct kvm_vcpu vcpu; + struct kvm_vm vm; + struct ucall uc; + + vcpu = create_l1_vcpu(&vm, l1_lmsle); + + vcpu_set_or_clear_cpuid_feature(vcpu, X86_FEATURE_EFER_LMSLE_MBZ, + lmsle_mbz); + + vcpu_run(vcpu); + TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_IO); + + switch (get_ucall(vcpu, &uc)) { + case UCALL_ABORT: + REPORT_GUEST_ASSERT(uc); + case UCALL_DONE: + break; + default: + TEST_FAIL("Unexpected ucall: %lu", uc.cmd); + } + + kvm_vm_free(vm); + ksft_test_result_pass("Guest EFER_LMSLE_MBZ=%d\n", lmsle_mbz); +} + +static void test_host_initiated_lmsle(void) +{ + struct kvm_vcpu vcpu; + struct kvm_vm vm; + u64 efer; + + vm = vm_create_with_one_vcpu(&vcpu, NULL); + vcpu_set_cpuid_feature(vcpu, X86_FEATURE_EFER_LMSLE_MBZ); + + / + * EFER_LMSLE_MBZ is a guest CPUID consistency check, not a host + * capability, i.e. must not be enforced against host-initiated writes, + * so that userspace can set MSRs before it sets guest CPUID. + / + efer = vcpu_get_msr(vcpu, MSR_EFER); + TEST_ASSERT(!(efer & EFER_LMSLE), "EFER.LMSLE unexpectedly set"); + + vcpu_set_msr(vcpu, MSR_EFER, efer \| EFER_LMSLE); + TEST_ASSERT_EQ(vcpu_get_msr(vcpu, MSR_EFER), efer \| EFER_LMSLE); + + kvm_vm_free(vm); + ksft_test_result_pass("Host-initiated EFER.LMSLE=1 is allowed\n"); +} + +static void test_sregs_lmsle(void) +{ + struct kvm_vcpu vcpu; + struct kvm_sregs sregs; + struct kvm_vm vm; + int rc; + + vm = vm_create_with_one_vcpu(&vcpu, NULL); + vcpu_set_cpuid_feature(vcpu, X86_FEATURE_EFER_LMSLE_MBZ); + + / + * Unlike KVM_SET_MSRS, KVM_SET_SREGS runs the full set of guest CPUID + * checks, i.e. rejects EFER.LMSLE even though it's host-initiated. + / + vcpu_sregs_get(vcpu, &sregs); + TEST_ASSERT(!(sregs.efer & EFER_LMSLE), "EFER.LMSLE unexpectedly set"); + + sregs.efer \|= EFER_LMSLE; + rc = _vcpu_sregs_set(vcpu, &sregs); + TEST_ASSERT(rc, "KVM allowed EFER.LMSLE with EFER_LMSLE_MBZ set"); + + kvm_vm_free(vm); + ksft_test_result_pass("KVM_SET_SREGS rejects EFER.LMSLE=1\n"); +} + +int main(int argc, char argv[]) +{ + bool has_nested_svm, has_lmsle; + + ksft_print_header(); + ksft_set_plan(6); + + test_enumeration(); + + /* + * The sub-tests below need to actually run a nested guest, and the + * EFER.LMSLE sub-tests additionally need KVM to allow EFER.LMSLE. + * It's KVM's view of the world, not raw CPUID, that dictates whether + * EFER.LMSLE is allowed, i.e. whether the defeature is emulated. + */ + has_nested_svm = kvm_cpu_has(X86_FEATURE_SVM); + has_lmsle = has_nested_svm && + !kvm_cpu_has(X86_FEATURE_EFER_LMSLE_MBZ); + + if (!has_nested_svm) + ksft_print_msg("Nested SVM unsupported\n"); + else if (!has_lmsle) + ksft_print_msg("KVM doesn't support EFER.LMSLE\n"); + + if (has_nested_svm) { + test_clear_efer_svme(); + test_lmsle(true); + } else { + ksft_test_result_skip("L2 clearing EFER.SVME shuts down L1\n"); + ksft_test_result_skip("Guest EFER_LMSLE_MBZ=1\n"); + } + + if (has_lmsle) { + test_lmsle(false); + test_host_initiated_lmsle(); + test_sregs_lmsle(); + } else { + ksft_test_result_skip("Guest EFER_LMSLE_MBZ=0\n"); + ksft_test_result_skip("Host-initiated EFER.LMSLE=1 is allowed\n"); + ksft_test_result_skip("KVM_SET_SREGS rejects EFER.LMSLE=1\n"); + } + + ksft_finished(); +}
27/3	2026/09/30 23:41	llm	kmsan-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 10800 output: 40 thoughts: 728 Thoughts: KMSAN Evaluation for KVM Patch Series Okay, so I need to decide if this kernel patch series warrants a dedicated KMSAN fuzzing run, or if KASAN and other standard bug detectors are sufficient. I know the rules: KMSAN is specifically for catching reads of uninitialized memory, both kernel-internal (stack, heap, allocations) and in potential kernel-to-user information leaks. I shouldn't bother with KMSAN if KASAN or other checks can catch the bug. I need to only flag `NeedsKMSAN=true` if the patch introduces new uninitialized memory risks that only KMSAN would detect, things like: * Structures sent to userspace with potentially uninitialized fields or padding. * Conditional logic relying on uninitialized variables. * Complex data structures with later-read uninitialized fields. * Bypassing bounds checks to expose uninitialized memory. Conversely, I should set `NeedsKMSAN=false` if it's primarily OOB, null pointer dereference, lock issues, or UAF bugs. If all stack/heap structures are initialized before reading, or if the patch doesn't introduce any uninitialized memory risks, it's a no-go for KMSAN. Alright, time to dig in. The patch touches these files: `Documentation/virt/kvm/api.rst`, `arch/x86/kvm/cpuid.c`, `arch/x86/kvm/msrs.c`, `arch/x86/kvm/svm/svm.c`, `arch/x86/kvm/vmx/vmx.c`, `arch/x86/kvm/x86.c`, and `tools/testing/selftests/kvm/*`. Let's examine the kernel changes in `arch/x86/kvm/cpuid.c` in detail first. I see a change in `kvm_initialize_cpu_caps` and then a section in `cpuid_func_emulated`. I'm seeing `PASSTHROUGH_F(EFER_LMSLE_MBZ)` in `kvm_initialize_cpu_caps`, and a conditional check and potential modification of an `entry` structure within `cpuid_func_emulated`. Wait a second. That `entry` structure is being manipulated within the conditional. I need to trace this `entry` variable. Is it user controlled? Where is `entry` defined and how is it passed to this function? I'll need to use `grepper` or `read-file` to check `cpuid_func_emulated` and its callers to trace the origin and usage of `entry`. If it is potentially uninitialized on the way into the function, then I may need to run this code through KMSAN.
28/3	2026/09/30 23:41	tool	grepper	0m Args: { "Expression": "cpuid_func_emulated", "PathPrefix": "arch/x86/kvm/cpuid.c" } Results: { "Output": "arch/x86/kvm/cpuid.c=356=static u32 cpuid_get_reg_unsafe(struct kvm_cpuid_entry2 entry, u32 reg)\n--\narch/x86/kvm/cpuid.c-372-\narch/x86/kvm/cpuid.c:373:static int cpuid_func_emulated(struct kvm_cpuid_entry2 entry, u32 func, u32 index,\narch/x86/kvm/cpuid.c-374-\t\t\t bool include_partially_emulated);\n--\narch/x86/kvm/cpuid.c=376=void kvm_vcpu_after_set_cpuid(struct kvm_vcpu vcpu)\n--\narch/x86/kvm/cpuid.c-402-\narch/x86/kvm/cpuid.c:403:\t\tcpuid_func_emulated(\u0026emulated, cpuid.function, cpuid.index, true);\narch/x86/kvm/cpuid.c-404-\n--\narch/x86/kvm/cpuid.c=1343=static struct kvm_cpuid_entry2 do_host_cpuid(struct kvm_cpuid_array array,\n--\narch/x86/kvm/cpuid.c-1385-\narch/x86/kvm/cpuid.c:1386:static int cpuid_func_emulated(struct kvm_cpuid_entry2 entry, u32 func, u32 index,\narch/x86/kvm/cpuid.c-1387-\t\t\t bool include_partially_emulated)\n--\narch/x86/kvm/cpuid.c-1442-\narch/x86/kvm/cpuid.c:1443:static int __do_cpuid_func_emulated(struct kvm_cpuid_array array, u32 func)\narch/x86/kvm/cpuid.c-1444-{\n--\narch/x86/kvm/cpuid.c-1447-\narch/x86/kvm/cpuid.c:1448:\tarray-\u003enent += cpuid_func_emulated(\u0026array-\u003eentries[array-\u003enent], func, 0, false);\narch/x86/kvm/cpuid.c-1449-\treturn 0;\n--\narch/x86/kvm/cpuid.c=1949=static int do_cpuid_func(struct kvm_cpuid_array array, u32 func,\n--\narch/x86/kvm/cpuid.c-1952-\tif (type == KVM_GET_EMULATED_CPUID)\narch/x86/kvm/cpuid.c:1953:\t\treturn __do_cpuid_func_emulated(array, func);\narch/x86/kvm/cpuid.c-1954-\n" }
29/3	2026/09/30 23:41	llm	kmsan-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 12959 output: 42 thoughts: 21 Thoughts: Here's my take on those thoughts, tailored for an expert audience: Analyzing `cpuid_func_emulated` for Potential Issues Alright, let's zero in on `cpuid_func_emulated` around line 1386. I'm immediately thinking about the emulation strategy being employed here. Given my experience, the specifics of this function are crucial. We need to dissect the emulation logic to ensure it accurately reflects the intended CPUID behavior across the target architecture and the emulated environment. What are the key emulation parameters in play? Are we properly handling all the relevant CPUID leaf functions and sub-leaf functions? Are there any obvious potential gaps in the emulation of edge cases? Any subtle differences, particularly regarding timing or side-channel behavior, that might create compatibility issues or security vulnerabilities? I'll need to confirm the emulation correctly handles privilege level changes, virtualization flags, and any potential interactions with hypervisor layers. The goal is complete behavioral equivalence, or at least, a precisely documented deviation from it. Let's see what we're working with here.
30/3	2026/09/30 23:41	tool	read-file	0m Args: { "File": "arch/x86/kvm/cpuid.c", "FirstLine": 1385, "LineCount": 50 } Results: { "Contents": "1385:\t\n1386:\tstatic int cpuid_func_emulated(struct kvm_cpuid_entry2 entry, u32 func, u32 index,\n1387:\t\t\t\t bool include_partially_emulated)\n1388:\t{\n1389:\t\tmemset(entry, 0, sizeof(entry));\n1390:\t\n1391:\t\t/* KVM doesn't currently emulate any non-zero indices. /\n1392:\t\tif (cpuid_function_is_indexed(func) \u0026\u0026 index)\n1393:\t\t\treturn 0;\n1394:\t\n1395:\t\tentry-\u003efunction = func;\n1396:\t\tentry-\u003eindex = 0;\n1397:\t\tentry-\u003eflags = 0;\n1398:\t\n1399:\t\tswitch (func) {\n1400:\t\tcase 0:\n1401:\t\t\tentry-\u003eeax = 7;\n1402:\t\t\treturn 1;\n1403:\t\tcase 1:\n1404:\t\t\tentry-\u003eecx = feature_bit(MOVBE);\n1405:\t\t\t/\n1406:\t\t\t * KVM allows userspace to enumerate MONITOR+MWAIT support to\n1407:\t\t\t * the guest, but the MWAIT feature flag is never advertised\n1408:\t\t\t * to userspace because MONITOR+MWAIT aren't virtualized by\n1409:\t\t\t * hardware, can't be faithfully emulated in software (KVM\n1410:\t\t\t * emulates them as NOPs), and allowing the guest to execute\n1411:\t\t\t * them natively requires enabling a per-VM capability.\n1412:\t\t\t /\n1413:\t\t\tif (include_partially_emulated)\n1414:\t\t\t\tentry-\u003eecx \|= feature_bit(MWAIT);\n1415:\t\t\treturn 1;\n1416:\t\tcase 7:\n1417:\t\t\tentry-\u003eflags \|= KVM_CPUID_FLAG_SIGNIFCANT_INDEX;\n1418:\t\t\tentry-\u003eeax = 0;\n1419:\t\t\tif (kvm_cpu_cap_has(X86_FEATURE_RDTSCP))\n1420:\t\t\t\tentry-\u003eecx = feature_bit(RDPID);\n1421:\t\t\treturn 1;\n1422:\t\tcase 0x80000008:\n1423:\t\t\t/\n1424:\t\t\t * Honor the guest's EFER_LMSLE_MBZ even if the underlying CPU\n1425:\t\t\t * allows setting EFER.LMSLE, e.g. to allow migrating a vCPU\n1426:\t\t\t * between hosts with and without EFER.LMSLE support. To avoid\n1427:\t\t\t * breaking existing setups that reflect KVM's supported CPUID\n1428:\t\t\t * into the guest, KVM doesn't advertise EFER_LMSLE_MBZ unless\n1429:\t\t\t * KVM can't support EFER.LMSLE=1.\n1430:\t\t\t */\n1431:\t\t\tif (include_partially_emulated \u0026\u0026\n1432:\t\t\t !kvm_cpu_cap_has(X86_FEATURE_EFER_LMSLE_MBZ)) {\n1433:\t\t\t\tentry-\u003eebx \|= feature_bit(EFER_LMSLE_MBZ);\n1434:\t\t\t\treturn 1;\n" }
31/3	2026/09/30 23:41	llm	kmsan-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 14123 output: 41 thoughts: 55 Thoughts: Okay, here's my take on those thoughts, framed as my own mental processing as an expert in the field: Debugging a KVM CPUID Issue: Initial Observations Right, let's see, I'm digging into this KVM CPUID behavior... and line 1389 immediately catches my eye: `memset(entry, 0, sizeof(entry));`. Okay, so `entry` is being explicitly* zeroed out. That's good practice, generally speaking, but it's important context. It tells me the author of this code cared enough to make sure this structure, whatever `entry` is, starts in a known state. This implies that there could be some assumptions downstream based on a zeroed initial state. Now, I need to understand what `entry` is and what it represents to fully grok the implications. The zero-initialization on its own doesn't tell me much, though it could be a sign that the logic is reliant on uninitialized data being explicitly zeroed. This is especially important for the CPUID functionality, which is rife with potential for security vulnerabilities if not coded correctly. The caller context will reveal whether this initialization is critical. I'm going to look at the surrounding code and try to figure out what's using it. The function name `kvm_vcpu_after_set_cpuid` is a strong clue, so I'll want to trace back to its callers. I'll need to understand the control flow surrounding this. This zeroing action is going to be important to understand the overall architecture.
32/3	2026/09/30 23:41	tool	read-file	0m Args: { "File": "arch/x86/kvm/cpuid.c", "FirstLine": 395, "LineCount": 25 } Results: { "Contents": " 395:\t\n 396:\t\t\tif (!cpuid.function)\n 397:\t\t\t\tcontinue;\n 398:\t\n 399:\t\t\tentry = kvm_find_cpuid_entry_index(vcpu, cpuid.function, cpuid.index);\n 400:\t\t\tif (!entry)\n 401:\t\t\t\tcontinue;\n 402:\t\n 403:\t\t\tcpuid_func_emulated(\u0026emulated, cpuid.function, cpuid.index, true);\n 404:\t\n 405:\t\t\t/\n 406:\t\t\t A vCPU has a feature if it's supported by KVM and is enabled\n 407:\t\t\t * in guest CPUID. Note, this includes features that are\n 408:\t\t\t * supported by KVM but aren't advertised to userspace!\n 409:\t\t\t /\n 410:\t\t\tvcpu-\u003earch.cpu_caps[i] = kvm_cpu_caps[i] \|\n 411:\t\t\t\t\t\t cpuid_get_reg_unsafe(\u0026emulated, cpuid.reg);\n 412:\t\t\tvcpu-\u003earch.cpu_caps[i] \u0026= cpuid_get_reg_unsafe(entry, cpuid.reg);\n 413:\t\t}\n 414:\t\n 415:\t\tkvm_update_cpuid_runtime(vcpu);\n 416:\t\n 417:\t\t/\n 418:\t\t * If TDP is enabled, let the guest use GBPAGES if they're supported in\n 419:\t\t * hardware. The hardware page walker doesn't let KVM disable GBPAGES,\n" }
33/3	2026/09/30 23:41	llm	kmsan-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 14976 output: 43 thoughts: 471 Thoughts: Analyzing CPUID and MSR Handling in KVM for x86 Okay, so I'm tracing through this KVM code, and I'm focusing on how it handles CPUID and MSRs, especially the EFER register. I see that when `cpuid_func_emulated` is called within `__do_cpuid_func_emulated`, and specifically when `include_partially_emulated` is `false`, it returns 0 for function 0x80000008. I need to keep that in mind as I continue digging. Now, I'm checking `arch/x86/kvm/msrs.c` to understand how EFER validation happens. The `__kvm_valid_efer` function is the key here. It checks the EFER register bits. I note the interesting logic around the `EFER_NX` and `EFER_LMSLE_MBZ` bits. Specifically, the check for `EFER_LMSLE_MBZ` is inverted compared to most other checks because it represents a "defeature." If the guest has `X86_FEATURE_EFER_LMSLE_MBZ` but `EFER_LMSLE` is set, it's considered invalid. I'm storing that rule for future debugging. I then move on to `arch/x86/kvm/svm/svm.c` and specifically the `efer_trap` function. I see that inside `efer_trap`, the code is setting up an MSR write. The important bit here is that the `msr_info.data` is set from the VMCB's exit info, but with `EFER_SVME` and `EFER_LMSLE` masked out. This suggests the hypervisor is manipulating the EFER value. The hypervisor is setting `msr_info.data = to_svm(vcpu)->vmcb->control.exit_info_1 & ~(EFER_SVME \| EFER_LMSLE);` before making the MSR write, which is then processed through `kvm_set_msr_common`. I will need to look into how this `exit_info_1` is being set and why the code is choosing to remove these particular bits.
34/3	2026/09/30 23:41	tool	read-file	0m Args: { "File": "arch/x86/kvm/svm/svm.c", "FirstLine": 2750, "LineCount": 35 } Results: { "Contents": "2750:\t}\n2751:\t\n2752:\tstatic int efer_trap(struct kvm_vcpu vcpu)\n2753:\t{\n2754:\t\tstruct msr_data msr_info;\n2755:\t\tint ret;\n2756:\t\n2757:\t\t/\n2758:\t\t * Clear the EFER_SVME bit from EFER. The SVM code always sets this\n2759:\t\t * bit in svm_set_efer(), but __kvm_valid_efer() checks it against\n2760:\t\t * whether the guest has X86_FEATURE_SVM - this avoids a failure if\n2761:\t\t * the guest doesn't have X86_FEATURE_SVM.\n2762:\t\t \n2763:\t\t Clear EFER_LMSLE for a related reason: EFER writes are trapped,\n2764:\t\t * not intercepted, i.e. hardware has already committed the write by\n2765:\t\t * the time KVM gains control, and the trap is enabled if and only if\n2766:\t\t * the guest is SEV-ES, whose EFER lives in the encrypted VMSA and so\n2767:\t\t * can't be fixed up by KVM. Rejecting EFER.LMSLE=1 would inject a #GP\n2768:\t\t * and leave EFER.LMSLE set in the guest, which is strictly worse\n2769:\t\t * than honoring a write that hardware itself allowed.\n2770:\t\t /\n2771:\t\tmsr_info.host_initiated = false;\n2772:\t\tmsr_info.index = MSR_EFER;\n2773:\t\tmsr_info.data = to_svm(vcpu)-\u003evmcb-\u003econtrol.exit_info_1 \u0026\n2774:\t\t\t\t~(EFER_SVME \| EFER_LMSLE);\n2775:\t\tret = kvm_set_msr_common(vcpu, \u0026msr_info);\n2776:\t\n2777:\t\treturn kvm_complete_insn_gp(vcpu, ret);\n2778:\t}\n2779:\t\n2780:\tstatic int svm_get_feature_msr(u32 msr, u64 data)\n2781:\t{\n2782:\t\t*data = 0;\n2783:\t\n2784:\t\tswitch (msr) {\n" }
35/3	2026/09/30 23:41	llm	kmsan-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 16626 output: 35 thoughts: 332 Thoughts: Analyzing EFER and CPU Capability Handling in KVM Okay, let's dive into this. I need to understand how KVM handles the Extended Feature Enable Register (EFER) and the associated CPU capabilities, specifically related to the `LMSLE_MBZ` bit. I see we have three key functions I need to analyze: `svm_set_cpu_caps`, `vmx_set_cpu_caps`, and `kvm_setup_efer_caps`. First, it seems like `svm_set_cpu_caps` sets the `X86_FEATURE_EFER_LMSLE_MBZ` feature, unless in a nested virtualization scenario, whereas `vmx_set_cpu_caps` always sets this capability. That's a point to investigate further, the difference between these two contexts. Why this difference? Next, `kvm_setup_efer_caps` is intriguing. It appears to be the central point for managing what EFER bits are considered "supported." The check for the `X86_FEATURE_SVM` feature indicates this is specific to AMD Secure Virtual Machine (SVM) environments. And it looks like the code conditionally sets the `EFER_SVME` bit in `kvm_caps.supported_efer_bits`. Now, the important part: it seems like we're enumerating `EFER_LMSLE_MBZ`, and the code explicitly avoids enabling `EFER.LMSLE=1` if `X86_FEATURE_EFER_LMSLE_MBZ` isn't supported. This makes sense. The comment is crucial; it highlights that KVM's capabilities are paramount, not just raw CPUID. We're defeaturing if KVM can't fully support it. But what does "fully support" mean? Now I need a broader view. I must trace the calls to `kvm_valid_efer` and `__kvm_valid_efer`. I need to see how these functions are used throughout the KVM codebase to determine the criteria for validating the EFER. This will paint a clearer picture of how KVM handles potential conflicts or limitations related to EFER's behavior in different environments, and if this logic is, indeed, correct and complete. I need to see how the supported capabilities from the previous code affect the validation and overall behavior.
36/3	2026/09/30 23:41	tool	grepper	0m Args: { "Expression": "kvm_valid_efer", "PathPrefix": "arch/x86/kvm" } Results: { "Output": "arch/x86/kvm/msrs.c=577=static int do_get_feature_msr(struct kvm_vcpu vcpu, unsigned index, u64 data)\n--\narch/x86/kvm/msrs.c-582-\narch/x86/kvm/msrs.c:583:static bool __kvm_valid_efer(struct kvm_vcpu vcpu, u64 efer)\narch/x86/kvm/msrs.c-584-{\n--\narch/x86/kvm/msrs.c-613-\narch/x86/kvm/msrs.c:614:bool kvm_valid_efer(struct kvm_vcpu vcpu, u64 efer)\narch/x86/kvm/msrs.c-615-{\n--\narch/x86/kvm/msrs.c-618-\narch/x86/kvm/msrs.c:619:\treturn __kvm_valid_efer(vcpu, efer);\narch/x86/kvm/msrs.c-620-}\narch/x86/kvm/msrs.c:621:EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_valid_efer);\narch/x86/kvm/msrs.c-622-\narch/x86/kvm/msrs.c=623=static int set_efer(struct kvm_vcpu vcpu, struct msr_data msr_info)\n--\narch/x86/kvm/msrs.c-632-\tif (!msr_info-\u003ehost_initiated) {\narch/x86/kvm/msrs.c:633:\t\tif (!__kvm_valid_efer(vcpu, efer))\narch/x86/kvm/msrs.c-634-\t\t\treturn 1;\n--\narch/x86/kvm/msrs.h=58=int kvm_get_reg_list(struct kvm_vcpu vcpu,\n--\narch/x86/kvm/msrs.h-60-\narch/x86/kvm/msrs.h:61:bool kvm_valid_efer(struct kvm_vcpu vcpu, u64 efer);\narch/x86/kvm/msrs.h-62-int kvm_emulate_msr_read(struct kvm_vcpu vcpu, u32 index, u64 data);\n--\narch/x86/kvm/regs.c=545=static bool kvm_is_valid_sregs(struct kvm_vcpu vcpu, struct kvm_sregs sregs)\n--\narch/x86/kvm/regs.c-567-\t kvm_is_valid_cr0(vcpu, sregs-\u003ecr0) \u0026\u0026\narch/x86/kvm/regs.c:568:\t kvm_valid_efer(vcpu, sregs-\u003eefer);\narch/x86/kvm/regs.c-569-}\n--\narch/x86/kvm/svm/nested.c=438=static bool nested_vmcb_check_save(struct kvm_vcpu vcpu,\n--\narch/x86/kvm/svm/nested.c-471-\narch/x86/kvm/svm/nested.c:472:\tif (CC(!kvm_valid_efer(vcpu, save-\u003eefer)))\narch/x86/kvm/svm/nested.c-473-\t\treturn false;\n--\narch/x86/kvm/svm/svm.c=2752=static int efer_trap(struct kvm_vcpu vcpu)\n--\narch/x86/kvm/svm/svm.c-2758-\t * Clear the EFER_SVME bit from EFER. The SVM code always sets this\narch/x86/kvm/svm/svm.c:2759:\t * bit in svm_set_efer(), but __kvm_valid_efer() checks it against\narch/x86/kvm/svm/svm.c-2760-\t * whether the guest has X86_FEATURE_SVM - this avoids a failure if\n--\narch/x86/kvm/vmx/nested.c=3175=static int nested_vmx_check_host_state(struct kvm_vcpu vcpu,\n--\narch/x86/kvm/vmx/nested.c-3237-\tif (vmcs12-\u003evm_exit_controls \u0026 VM_EXIT_LOAD_IA32_EFER) {\narch/x86/kvm/vmx/nested.c:3238:\t\tif (CC(!kvm_valid_efer(vcpu, vmcs12-\u003ehost_ia32_efer)) \|\|\narch/x86/kvm/vmx/nested.c-3239-\t\t CC(ia32e != !!(vmcs12-\u003ehost_ia32_efer \u0026 EFER_LMA)) \|\|\n--\narch/x86/kvm/vmx/nested.c=3311=static int nested_vmx_check_guest_state(struct kvm_vcpu vcpu,\n--\narch/x86/kvm/vmx/nested.c-3376-\t (vmcs12-\u003evm_entry_controls \u0026 VM_ENTRY_LOAD_IA32_EFER)) {\narch/x86/kvm/vmx/nested.c:3377:\t\tif (CC(!kvm_valid_efer(vcpu, vmcs12-\u003eguest_ia32_efer)) \|\|\narch/x86/kvm/vmx/nested.c-3378-\t\t CC(ia32e != !!(vmcs12-\u003eguest_ia32_efer \u0026 EFER_LMA)) \|\|\n" }
37/3	2026/09/30 23:41	llm	kmsan-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 19024 output: 35 thoughts: 166 Thoughts: Okay, let's break this down. Analyzing the `kvm_valid_efer` Function Calls Alright, so `kvm_valid_efer` is being called from a few key locations: `set_efer`, `kvm_is_valid_sregs`, the nested SVM check save, and also the nested VMX check for both host and guest states. These all pass a `u64 efer` value along with a `struct kvm_vcpu *vcpu` pointer to the `kvm_valid_efer` function. That gives me a good overview of the function's responsibility and its context of use. Now, inside `__kvm_valid_efer`, the code's checking whether the CPU supports the `X86_FEATURE_EFER_LMSLE_MBZ` feature, using `guest_cpu_cap_has(vcpu, X86_FEATURE_EFER_LMSLE_MBZ)`. I need to figure out what `guest_cpu_cap_has` does. I'll take a look at its definition, because that's where the real magic happens. This looks like a conditional branch based on CPU capabilities, and knowing how those capabilities are determined is key.
38/3	2026/09/30 23:41	tool	grepper	0m Args: { "Expression": "guest_cpu_cap_has", "PathPrefix": "arch/x86/kvm" } Results: { "Output": "\nFull output is too long, showing 200 out of 805 lines.\nUse more precise expression if possible.\n\narch/x86/kvm/cpuid.c=376=void kvm_vcpu_after_set_cpuid(struct kvm_vcpu vcpu)\n--\narch/x86/kvm/cpuid.c-428-\tallow_gbpages = tdp_enabled ? boot_cpu_has(X86_FEATURE_GBPAGES) :\narch/x86/kvm/cpuid.c:429:\t\t\t\t guest_cpu_cap_has(vcpu, X86_FEATURE_GBPAGES);\narch/x86/kvm/cpuid.c-430-\tguest_cpu_cap_change(vcpu, X86_FEATURE_GBPAGES, allow_gbpages);\n--\narch/x86/kvm/cpuid.c-454-\tvcpu-\u003earch.cr4_guest_rsvd_bits = __cr4_reserved_bits(__kvm_cpu_cap_has, UNUSED_) \|\narch/x86/kvm/cpuid.c:455:\t\t\t\t\t __cr4_reserved_bits(guest_cpu_cap_has, vcpu);\narch/x86/kvm/cpuid.c-456-#undef __kvm_cpu_cap_has\n--\narch/x86/kvm/cpuid.h=258=static __always_inline void guest_cpu_cap_change(struct kvm_vcpu vcpu,\n--\narch/x86/kvm/cpuid.h-267-\narch/x86/kvm/cpuid.h:268:static __always_inline bool guest_cpu_cap_has(struct kvm_vcpu vcpu,\narch/x86/kvm/cpuid.h-269-\t\t\t\t\t unsigned int x86_feature)\n--\narch/x86/kvm/cpuid.h=284=static inline bool kvm_vcpu_is_legal_cr3(struct kvm_vcpu vcpu, unsigned long cr3)\narch/x86/kvm/cpuid.h-285-{\narch/x86/kvm/cpuid.h:286:\tif (guest_cpu_cap_has(vcpu, X86_FEATURE_LAM))\narch/x86/kvm/cpuid.h-287-\t\tcr3 \u0026= ~(X86_CR3_LAM_U48 \| X86_CR3_LAM_U57);\n--\narch/x86/kvm/cpuid.h=292=static inline bool guest_has_spec_ctrl_msr(struct kvm_vcpu vcpu)\narch/x86/kvm/cpuid.h-293-{\narch/x86/kvm/cpuid.h:294:\treturn (guest_cpu_cap_has(vcpu, X86_FEATURE_SPEC_CTRL) \|\|\narch/x86/kvm/cpuid.h:295:\t\tguest_cpu_cap_has(vcpu, X86_FEATURE_AMD_STIBP) \|\|\narch/x86/kvm/cpuid.h:296:\t\tguest_cpu_cap_has(vcpu, X86_FEATURE_AMD_IBRS) \|\|\narch/x86/kvm/cpuid.h:297:\t\tguest_cpu_cap_has(vcpu, X86_FEATURE_AMD_SSBD));\narch/x86/kvm/cpuid.h-298-}\n--\narch/x86/kvm/cpuid.h=300=static inline bool guest_has_pred_cmd_msr(struct kvm_vcpu vcpu)\narch/x86/kvm/cpuid.h-301-{\narch/x86/kvm/cpuid.h:302:\treturn (guest_cpu_cap_has(vcpu, X86_FEATURE_SPEC_CTRL) \|\|\narch/x86/kvm/cpuid.h:303:\t\tguest_cpu_cap_has(vcpu, X86_FEATURE_AMD_IBPB) \|\|\narch/x86/kvm/cpuid.h:304:\t\tguest_cpu_cap_has(vcpu, X86_FEATURE_SBPB));\narch/x86/kvm/cpuid.h-305-}\n--\narch/x86/kvm/hyperv.c=1358=static void __kvm_hv_xsaves_xsavec_maybe_warn(struct kvm_vcpu vcpu)\n--\narch/x86/kvm/hyperv.c-1377-\tif (guest_cpuid_has(vcpu, X86_FEATURE_XSAVES) \|\|\narch/x86/kvm/hyperv.c:1378:\t !guest_cpu_cap_has(vcpu, X86_FEATURE_XSAVEC))\narch/x86/kvm/hyperv.c-1379-\t\treturn;\n--\narch/x86/kvm/lapic.c=614=void kvm_apic_set_version(struct kvm_vcpu vcpu)\n--\narch/x86/kvm/lapic.c-624-\narch/x86/kvm/lapic.c:625:\tif (guest_cpu_cap_has(vcpu, X86_FEATURE_X2APIC) \u0026\u0026\narch/x86/kvm/lapic.c-626-\t kvm_lapic_advertise_suppress_eoi_broadcast(vcpu-\u003ekvm))\n--\narch/x86/kvm/lapic.c=2849=int kvm_apic_set_base(struct kvm_vcpu vcpu, u64 value, bool host_initiated)\n--\narch/x86/kvm/lapic.c-2857-\tu64 reserved_bits = kvm_vcpu_reserved_gpa_bits_raw(vcpu) \| 0x2ff \|\narch/x86/kvm/lapic.c:2858:\t\t(guest_cpu_cap_has(vcpu, X86_FEATURE_X2APIC) ? 0 : X2APIC_ENABLE);\narch/x86/kvm/lapic.c-2859-\n--\narch/x86/kvm/mmu.h=229=static inline unsigned long kvm_get_active_cr3_lam_bits(struct kvm_vcpu vcpu)\narch/x86/kvm/mmu.h-230-{\narch/x86/kvm/mmu.h:231:\tif (!guest_cpu_cap_has(vcpu, X86_FEATURE_LAM))\narch/x86/kvm/mmu.h-232-\t\treturn 0;\n--\narch/x86/kvm/mmu/mmu.c=5513=static void reset_guest_rsvds_bits_mask(struct kvm_vcpu vcpu,\n--\narch/x86/kvm/mmu/mmu.c-5518-\t\t\t\tw-\u003ecpu_role.base.level, is_efer_nx(w),\narch/x86/kvm/mmu/mmu.c:5519:\t\t\t\tguest_cpu_cap_has(vcpu, X86_FEATURE_GBPAGES),\narch/x86/kvm/mmu/mmu.c-5520-\t\t\t\tis_cr4_pse(w),\n--\narch/x86/kvm/mmu/mmu.c=5580=static void reset_shadow_zero_bits_mask(struct kvm_vcpu vcpu,\n--\narch/x86/kvm/mmu/mmu.c-5595-\t\t\t\tcontext-\u003eroot_role.efer_nx,\narch/x86/kvm/mmu/mmu.c:5596:\t\t\t\tguest_cpu_cap_has(vcpu, X86_FEATURE_GBPAGES),\narch/x86/kvm/mmu/mmu.c-5597-\t\t\t\tis_pse, is_amd);\n--\narch/x86/kvm/msrs.c=583=static bool __kvm_valid_efer(struct kvm_vcpu vcpu, u64 efer)\narch/x86/kvm/msrs.c-584-{\narch/x86/kvm/msrs.c:585:\tif (efer \u0026 EFER_AUTOIBRS \u0026\u0026 !guest_cpu_cap_has(vcpu, X86_FEATURE_AUTOIBRS))\narch/x86/kvm/msrs.c-586-\t\treturn false;\narch/x86/kvm/msrs.c-587-\narch/x86/kvm/msrs.c:588:\tif (efer \u0026 EFER_FFXSR \u0026\u0026 !guest_cpu_cap_has(vcpu, X86_FEATURE_FXSR_OPT))\narch/x86/kvm/msrs.c-589-\t\treturn false;\narch/x86/kvm/msrs.c-590-\narch/x86/kvm/msrs.c:591:\tif (efer \u0026 EFER_SVME \u0026\u0026 !guest_cpu_cap_has(vcpu, X86_FEATURE_SVM))\narch/x86/kvm/msrs.c-592-\t\treturn false;\n--\narch/x86/kvm/msrs.c-594-\tif (efer \u0026 (EFER_LME \| EFER_LMA) \u0026\u0026\narch/x86/kvm/msrs.c:595:\t !guest_cpu_cap_has(vcpu, X86_FEATURE_LM))\narch/x86/kvm/msrs.c-596-\t\treturn false;\narch/x86/kvm/msrs.c-597-\narch/x86/kvm/msrs.c:598:\tif (efer \u0026 EFER_NX \u0026\u0026 !guest_cpu_cap_has(vcpu, X86_FEATURE_NX))\narch/x86/kvm/msrs.c-599-\t\treturn false;\n--\narch/x86/kvm/msrs.c-607-\tif (efer \u0026 EFER_LMSLE \u0026\u0026\narch/x86/kvm/msrs.c:608:\t guest_cpu_cap_has(vcpu, X86_FEATURE_EFER_LMSLE_MBZ))\narch/x86/kvm/msrs.c-609-\t\treturn false;\n--\narch/x86/kvm/msrs.c=709=static int __kvm_set_msr(struct kvm_vcpu vcpu, u32 index, u64 data,\n--\narch/x86/kvm/msrs.c-743-\t\tif (!host_initiated \u0026\u0026\narch/x86/kvm/msrs.c:744:\t\t !guest_cpu_cap_has(vcpu, X86_FEATURE_RDTSCP) \u0026\u0026\narch/x86/kvm/msrs.c:745:\t\t !guest_cpu_cap_has(vcpu, X86_FEATURE_RDPID))\narch/x86/kvm/msrs.c-746-\t\t\treturn 1;\n--\narch/x86/kvm/msrs.c-763-\tcase MSR_IA32_S_CET:\narch/x86/kvm/msrs.c:764:\t\tif (!guest_cpu_cap_has(vcpu, X86_FEATURE_SHSTK) \u0026\u0026\narch/x86/kvm/msrs.c:765:\t\t !guest_cpu_cap_has(vcpu, X86_FEATURE_IBT))\narch/x86/kvm/msrs.c-766-\t\t\treturn KVM_MSR_RET_UNSUPPORTED;\n--\narch/x86/kvm/msrs.c-785-\tcase MSR_IA32_PL0_SSP ... MSR_IA32_INT_SSP_TAB:\narch/x86/kvm/msrs.c:786:\t\tif (!guest_cpu_cap_has(vcpu, X86_FEATURE_SHSTK))\narch/x86/kvm/msrs.c-787-\t\t\treturn KVM_MSR_RET_UNSUPPORTED;\n--\narch/x86/kvm/msrs.c-791-\t\t /\narch/x86/kvm/msrs.c:792:\t\tif (index == MSR_IA32_INT_SSP_TAB \u0026\u0026 !guest_cpu_cap_has(vcpu, X86_FEATURE_LM))\narch/x86/kvm/msrs.c-793-\t\t\treturn KVM_MSR_RET_UNSUPPORTED;\n--\narch/x86/kvm/msrs.c=828=static int __kvm_get_msr(struct kvm_vcpu vcpu, u32 index, u64 data,\n--\narch/x86/kvm/msrs.c-839-\t\tif (!host_initiated \u0026\u0026\narch/x86/kvm/msrs.c:840:\t\t !guest_cpu_cap_has(vcpu, X86_FEATURE_RDTSCP) \u0026\u0026\narch/x86/kvm/msrs.c:841:\t\t !guest_cpu_cap_has(vcpu, X86_FEATURE_RDPID))\narch/x86/kvm/msrs.c-842-\t\t\treturn 1;\n--\narch/x86/kvm/msrs.c-845-\tcase MSR_IA32_S_CET:\narch/x86/kvm/msrs.c:846:\t\tif (!guest_cpu_cap_has(vcpu, X86_FEATURE_SHSTK) \u0026\u0026\narch/x86/kvm/msrs.c:847:\t\t !guest_cpu_cap_has(vcpu, X86_FEATURE_IBT))\narch/x86/kvm/msrs.c-848-\t\t\treturn KVM_MSR_RET_UNSUPPORTED;\n--\narch/x86/kvm/msrs.c-854-\tcase MSR_IA32_PL0_SSP ... MSR_IA32_INT_SSP_TAB:\narch/x86/kvm/msrs.c:855:\t\tif (!guest_cpu_cap_has(vcpu, X86_FEATURE_SHSTK))\narch/x86/kvm/msrs.c-856-\t\t\treturn KVM_MSR_RET_UNSUPPORTED;\n--\narch/x86/kvm/msrs.c=1180=static bool is_xstate_managed_msr(struct kvm_vcpu vcpu, u32 msr)\n--\narch/x86/kvm/msrs.c-1186-\tcase MSR_IA32_U_CET:\narch/x86/kvm/msrs.c:1187:\t\treturn guest_cpu_cap_has(vcpu, X86_FEATURE_SHSTK) \|\|\narch/x86/kvm/msrs.c:1188:\t\t guest_cpu_cap_has(vcpu, X86_FEATURE_IBT);\narch/x86/kvm/msrs.c-1189-\tcase MSR_IA32_PL0_SSP ... MSR_IA32_PL3_SSP:\narch/x86/kvm/msrs.c:1190:\t\treturn guest_cpu_cap_has(vcpu, X86_FEATURE_SHSTK);\narch/x86/kvm/msrs.c-1191-\tdefault:\n--\narch/x86/kvm/msrs.c=1452=int kvm_set_msr_common(struct kvm_vcpu vcpu, struct msr_data msr_info)\n--\narch/x86/kvm/msrs.c-1482-\t\tif (!msr_info-\u003ehost_initiated \|\|\narch/x86/kvm/msrs.c:1483:\t\t !guest_cpu_cap_has(vcpu, X86_FEATURE_ARCH_CAPABILITIES))\narch/x86/kvm/msrs.c-1484-\t\t\treturn KVM_MSR_RET_UNSUPPORTED;\n--\narch/x86/kvm/msrs.c-1488-\t\tif (!msr_info-\u003ehost_initiated \|\|\narch/x86/kvm/msrs.c:1489:\t\t !guest_cpu_cap_has(vcpu, X86_FEATURE_PDCM))\narch/x86/kvm/msrs.c-1490-\t\t\treturn KVM_MSR_RET_UNSUPPORTED;\n--\narch/x86/kvm/msrs.c-1513-\narch/x86/kvm/msrs.c:1514:\t\t\tif (!guest_cpu_cap_has(vcpu, X86_FEATURE_SPEC_CTRL) \u0026\u0026\narch/x86/kvm/msrs.c:1515:\t\t\t !guest_cpu_cap_has(vcpu, X86_FEATURE_AMD_IBPB))\narch/x86/kvm/msrs.c-1516-\t\t\t\treserved_bits \|= PRED_CMD_IBPB;\narch/x86/kvm/msrs.c-1517-\narch/x86/kvm/msrs.c:1518:\t\t\tif (!guest_cpu_cap_has(vcpu, X86_FEATURE_SBPB))\narch/x86/kvm/msrs.c-1519-\t\t\t\treserved_bits \|= PRED_CMD_SBPB;\n--\narch/x86/kvm/msrs.c-1538-\t\tif (!msr_info-\u003ehost_initiated \u0026\u0026\narch/x86/kvm/msrs.c:1539:\t\t !guest_cpu_cap_has(vcpu, X86_FEATURE_FLUSH_L1D))\narch/x86/kvm/msrs.c-1540-\t\t\treturn 1;\n--\narch/x86/kvm/msrs.c-1562-\narch/x86/kvm/msrs.c:1563:\t\tif (guest_cpu_cap_has(vcpu, X86_FEATURE_GP_ON_USER_CPUID))\narch/x86/kvm/msrs.c-1564-\t\t\tvalid \|= MSR_K7_HWCR_CPUID_USER_DIS;\n--\narch/x86/kvm/msrs.c-1595-\tcase MSR_IA32_TSC_ADJUST:\narch/x86/kvm/msrs.c:1596:\t\tif (guest_cpu_cap_has(vcpu, X86_FEATURE_TSC_ADJUST)) {\narch/x86/kvm/msrs.c-1597-\t\t\tif (!msr_info-\u003ehost_initiated) {\n--\narch/x86/kvm/msrs.c-1622-\t\t ((old_val ^ data) \u0026 MSR_IA32_MISC_ENABLE_MWAIT)) {\narch/x86/kvm/msrs.c:1623:\t\t\tif (!guest_cpu_cap_has(vcpu, X86_FEATURE_XMM3))\narch/x86/kvm/msrs.c-1624-\t\t\t\treturn 1;\n--\narch/x86/kvm/msrs.c-1801-\tcase MSR_AMD64_OSVW_ID_LENGTH:\narch/x86/kvm/msrs.c:1802:\t\tif (!guest_cpu_cap_has(vcpu, X86_FEATURE_OSVW))\narch/x86/kvm/msrs.c-1803-\t\t\treturn 1;\n--\narch/x86/kvm/msrs.c-1806-\tcase MSR_AMD64_OSVW_STATUS:\narch/x86/kvm/msrs.c:1807:\t\tif (!guest_cpu_cap_has(vcpu, X86_FEATURE_OSVW))\narch/x86/kvm/msrs.c-1808-\t\t\treturn 1;\n--\narch/x86/kvm/msrs.c-1825-\t\tif (!msr_info-\u003ehost_initiated \u0026\u0026\narch/x86/kvm/msrs.c:1826:\t\t !guest_cpu_cap_has(vcpu, X86_FEATURE_XFD))\narch/x86/kvm/msrs.c-1827-\t\t\treturn 1;\n--\narch/x86/kvm/msrs.c-1835-\t\tif (!msr_info-\u003ehost_initiated \u0026\u0026\narch/x86/kvm/msrs.c:1836:\t\t !guest_cpu_cap_has(vcpu, X86_FEATURE_XFD))\narch/x86/kvm/msrs.c-1837-\t\t\treturn 1;\n--\narch/x86/kvm/msrs.c=1909=int kvm_get_msr_common(struct kvm_vcpu vcpu, struct msr_data msr_info)\n--\narch/x86/kvm/msrs.c-1954-\tcase MSR_IA32_ARCH_CAPABILITIES:\narch/x86/kvm/msrs.c:1955:\t\tif (!guest_cpu_cap_has(vcpu, X86_FEATURE_ARCH_CAPABILITIES))\narch/x86/kvm/msrs.c-1956-\t\t\treturn KVM_MSR_RET_UNSUPPORTED;\n--\narch/x86/kvm/msrs.c-1959-\tcase MSR_IA32_PERF_CAPABILITIES:\narch/x86/kvm/msrs.c:1960:\t\tif (!guest_cpu_cap_has(vcpu, X86_FEATURE_PDCM))\narch/x86/kvm/msrs.c-1961-\t\t\treturn KVM_MSR_RET_UNSUPPORTED;\n--\narch/x86/kvm/msrs.c-2160-\tcase MSR_AMD64_OSVW_ID_LENGTH:\narch/x86/kvm/msrs.c:2161:\t\tif (!guest_cpu_cap_has(vcpu, X86_FEATURE_OSVW))\n\n" }
39/3	2026/09/30 23:41	llm	kmsan-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 25286 output: 362 thoughts: 2162 Thoughts: KMSAN Assessment: EFER_LMSLE_MBZ Patch Alright, let's break down this patch and figure out the KMSAN implications. First, the patch adds documentation for `EFER_LMSLE_MBZ`, which is purely informational, so that's a non-issue. Then, the core of the change appears to be centered around handling AMD's requirement that this feature bit be zero in certain situations. The changes touch various KVM components across the x86 architecture, specifically `cpuid.c`, `msrs.c`, `svm.c`, `vmx.c`, and `x86.c`, as well as a few selftests. My primary concern, in this context, is potential information leaks or undefined behavior arising from uninitialized memory. Let's see: In `cpuid.c`, we're dealing with CPUID emulation. The code adds logic to handle `EFER_LMSLE_MBZ`. Crucially, whenever a `cpuid_entry2` structure (the `entry`) is used, it's explicitly initialized with `memset(entry, 0, sizeof(entry))`. This eliminates any possibility of uninitialized memory being read or leaked to the guest. Even when a `cpuid_entry2` is passed from userspace, it is zeroed out. Next, we look at MSR handling in `msrs.c`. The `__kvm_valid_efer()` function now checks for `EFER_LMSLE` in conjunction with a CPU feature flag. This function operates on CPUID features and MSR data, and does not seem to make or read uninitialized memory, only bitwise checks. The `efer_trap()` handler in `svm.c` modifies MSR data, specifically by masking out some EFER bits. We do not need to worry, because there is only bitwise operations on values, not structures, and the structure is fully initialized. Similarly, `svm_set_cpu_caps()` and `vmx_set_cpu_caps()`, and `kvm_setup_efer_caps()` manipulate KVM CPU capabilities using functions like `kvm_cpu_cap_set` and `kvm_cpu_cap_has`. Again, we are operating on bitmasks, not complex data structures that might harbor uninitialized fields. The central question here is whether any of these changes introduce a risk of reading uninitialized memory, leaking it to userspace, or causing branching logic to depend on undefined values. Based on this thorough review, I can confidently say that the patch does not* introduce these risks. The data being manipulated are scalar CPUID feature bits, MSR register values, and flags. All structures involved are either fully initialized or zeroed. Therefore, since none of the KMSAN criteria (kernel structures sent to userspace with uninitialized fields, branching on uninitialized variables, allocation of complex data structures with uninitialized fields, or changes in bounds checks) are met, NeedsKMSAN should be set to false. There are no changes that would allow the existing code to access uninitialized memory. The patch is about emulation/checking/and manipulation of CPU features, MSRs, and capability flags; that is, bitmasks and bitwise operations. This is a clear case where KMSAN is not applicable.
40/3	2026/09/30 23:41	tool	set-results	0m Args: { "KMSANReasoning": "The patch series updates KVM's handling of the AMD EFER_LMSLE_MBZ (EFER Long Mode Segment Limit Enable Must Be Zero) feature bit across CPUID emulation and MSR validity checking (in cpuid.c, msrs.c, svm.c, vmx.c, and x86.c).\n\nReviewing the changes for KMSAN applicability:\n1. No uninitialized memory usage: All modifications deal with CPU capability bitmasks and MSR validity validation logic.\n2. In `cpuid_func_emulated()`, the modified `struct kvm_cpuid_entry2 entry` is fully zero-initialized at the start of the function via `memset(entry, 0, sizeof(entry))`. Furthermore, for func 0x80000008, it returns 0 when called from `KVM_GET_EMULATED_CPUID` (`include_partially_emulated` is false).\n3. The only other structure touched is `struct msr_data msr_info` in `efer_trap()`, which already had all its fields explicitly initialized, and the patch merely adjusts bitwise masking on `msr_info.data`.\n4. No heap or stack buffers are allocated, no struct paddings or uninitialized fields are exposed to userspace or the guest, and no buffer bounds or length checks are altered.\n\nTherefore, this patch does not introduce any risks related to uninitialized memory reads or kernel info-leaks, and running a dedicated KMSAN fuzzing session is not warranted.", "NeedsKMSAN": false } Results: { "KMSANReasoning": "The patch series updates KVM's handling of the AMD EFER_LMSLE_MBZ (EFER Long Mode Segment Limit Enable Must Be Zero) feature bit across CPUID emulation and MSR validity checking (in cpuid.c, msrs.c, svm.c, vmx.c, and x86.c).\n\nReviewing the changes for KMSAN applicability:\n1. No uninitialized memory usage: All modifications deal with CPU capability bitmasks and MSR validity validation logic.\n2. In `cpuid_func_emulated()`, the modified `struct kvm_cpuid_entry2 entry` is fully zero-initialized at the start of the function via `memset(entry, 0, sizeof(entry))`. Furthermore, for func 0x80000008, it returns 0 when called from `KVM_GET_EMULATED_CPUID` (`include_partially_emulated` is false).\n3. The only other structure touched is `struct msr_data msr_info` in `efer_trap()`, which already had all its fields explicitly initialized, and the patch merely adjusts bitwise masking on `msr_info.data`.\n4. No heap or stack buffers are allocated, no struct paddings or uninitialized fields are exposed to userspace or the guest, and no buffer bounds or length checks are altered.\n\nTherefore, this patch does not introduce any risks related to uninitialized memory reads or kernel info-leaks, and running a dedicated KMSAN fuzzing session is not warranted.", "NeedsKMSAN": false }

LLM Calls Summary:
Total Calls	Total Tokens	Avg Tokens	Total Duration (Seconds)	Avg Duration (Seconds)

Tool Calls Summary:
Total Calls	Total Duration (Seconds)	Avg Duration (Seconds)