AI Trajectory

Trajectory: (Expand/Collapse All)
Seq	Timestamp	Type	Name	Duration
0/0	2026/07/21 03:47	flow	patch-triage	0m Args: null Results: { "EnableConfigs": [ "KVM" ], "FocusSymbols": [ "kvm_pmu_instruction_retired", "kvm_pmu_branch_retired" ], "Reasoning": "This patch introduces a new KVM capability `KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING` that alters the behavior of software accounting for KVM-emulated instructions. It modifies core KVM PMU logic and should be fuzzed to ensure the capability is handled correctly and doesn't introduce regressions or vulnerabilities.", "WorthFuzzing": true }
1/1	2026/07/21 03:47	action	read-patch-diff	0m Args: null Results: { "PatchDiff": "commit a1efd12e06a5471be739c918a04e81b6ea095605\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Tue Jul 21 03:47:35 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 a5f9ee92f43e8d..231a5ba7567c51 100644\n--- a/Documentation/virt/kvm/api.rst\n+++ b/Documentation/virt/kvm/api.rst\n@@ -8949,6 +8949,38 @@ enabled, cmma can't be enabled anymore and pfmfi and the storage key\n interpretation are disabled. If cmma has already been enabled or the\n hpage_2g module parameter is not set to 1, -EINVAL is returned.\n \n+7.48 KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING\n+------------------------------------------\n+\n+:Architectures: x86\n+:Type: vm\n+:Parameters: args[0] - bitmask of PERF_COUNT_HW_* event IDs\n+:Returns: 0 on success; -EINVAL if args[0] contains an unsupported event or\n+ if the VM already has vCPUs.\n+\n+By default, KVM software-accounts instructions it emulates against a guest\n+PMU counter programmed for retired instructions (PERF_COUNT_HW_INSTRUCTIONS)\n+or retired branches (PERF_COUNT_HW_BRANCH_INSTRUCTIONS), by walking the vPMU\n+counters and requesting a counter reprogram on the next VM-entry. On hosts\n+with an emulated vPMU this reprogram is expensive and, under some workloads,\n+inflates timer-interrupt handling enough to trigger guest CSD lockups.\n+\n+This capability lets userspace disable that software accounting for the given\n+events. Setting a bit for an event ID makes KVM skip the accounting for that\n+event: instructions KVM emulates in host context go uncounted. Hardware-\n+executed guest instructions are still counted by the backing perf_event, and\n+its overflow/PMI path is unaffected.\n+\n+The capability only affects the emulated (perf-based) vPMU. A mediated vPMU\n+does not incur the reprogram cost and increments the guest counter directly,\n+so accounting is never skipped for it regardless of this setting.\n+\n+This can only be invoked on a VM prior to the creation of vCPUs; attempting to\n+set it once any vCPU exists returns -EINVAL.\n+\n+KVM_CHECK_EXTENSION returns the bitmask of event IDs that can be disabled.\n+args[0] must be a subset of that mask.\n+\n 8. Other capabilities.\n ======================\n \ndiff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h\nindex 5f6c1ce9673b7f..522f66c44e6a00 100644\n--- a/arch/x86/include/asm/kvm_host.h\n+++ b/arch/x86/include/asm/kvm_host.h\n@@ -1560,6 +1560,13 @@ struct kvm_arch {\n \tbool enable_pmu;\n \tbool created_mediated_pmu;\n \n+\t/\n+\t Bitmask of PERF_COUNT_HW_* event IDs for which software accounting\n+\t * of KVM-emulated instructions is disabled (KVM_CAP_X86_DISABLE_PMU_\n+\t * SW_ACCOUNTING). See kvm_pmu_trigger_event().\n+\t /\n+\tu64 pmu_disable_sw_accounting;\n+\n \tu32 notify_window;\n \tu32 notify_vmexit_flags;\n \t/\ndiff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c\nindex dd1c57593f48b8..fb3f2df068dc47 100644\n--- a/arch/x86/kvm/pmu.c\n+++ b/arch/x86/kvm/pmu.c\n@@ -1145,14 +1145,35 @@ static void kvm_pmu_trigger_event(struct kvm_vcpu vcpu,\n \tsrcu_read_unlock(\u0026vcpu-\u003ekvm-\u003esrcu, idx);\n }\n \n+/\n+ * Whether software accounting of KVM-emulated instructions for @perf_hw_id is\n+ * disabled via KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING. The capability only\n+ * targets the emulated (perf-based) vPMU, where the accounting drives an\n+ * expensive counter reprogram; a mediated vPMU increments pmc-\u003ecounter\n+ * directly (and may raise a PMI on overflow), so it is never skipped.\n+ /\n+static bool kvm_pmu_skip_sw_accounting(struct kvm_vcpu vcpu, u64 perf_hw_id)\n+{\n+\tif (kvm_vcpu_has_mediated_pmu(vcpu))\n+\t\treturn false;\n+\n+\treturn vcpu-\u003ekvm-\u003earch.pmu_disable_sw_accounting \u0026 BIT_ULL(perf_hw_id);\n+}\n+\n void kvm_pmu_instruction_retired(struct kvm_vcpu vcpu)\n {\n+\tif (kvm_pmu_skip_sw_accounting(vcpu, PERF_COUNT_HW_INSTRUCTIONS))\n+\t\treturn;\n+\n \tkvm_pmu_trigger_event(vcpu, vcpu_to_pmu(vcpu)-\u003epmc_counting_instructions);\n }\n EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_pmu_instruction_retired);\n \n void kvm_pmu_branch_retired(struct kvm_vcpu vcpu)\n {\n+\tif (kvm_pmu_skip_sw_accounting(vcpu, PERF_COUNT_HW_BRANCH_INSTRUCTIONS))\n+\t\treturn;\n+\n \tkvm_pmu_trigger_event(vcpu, vcpu_to_pmu(vcpu)-\u003epmc_counting_branches);\n }\n EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_pmu_branch_retired);\ndiff --git a/arch/x86/kvm/pmu.h b/arch/x86/kvm/pmu.h\nindex a5821d7c87f935..e34b9e81435557 100644\n--- a/arch/x86/kvm/pmu.h\n+++ b/arch/x86/kvm/pmu.h\n@@ -23,6 +23,15 @@\n \n #define KVM_FIXED_PMC_BASE_IDX INTEL_PMC_IDX_FIXED\n \n+/\n+ Events for which KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING can disable software\n+ * accounting of emulated instructions. These are the only events KVM ever\n+ * passes to kvm_pmu_trigger_event() (from the retired-instruction path).\n+ /\n+#define KVM_PMU_SW_ACCOUNTING_VALID_MASK\t\t\t\\\n+\t(BIT_ULL(PERF_COUNT_HW_INSTRUCTIONS) \|\t\t\t\\\n+\t BIT_ULL(PERF_COUNT_HW_BRANCH_INSTRUCTIONS))\n+\n struct kvm_pmu_ops {\n \tstruct kvm_pmc (rdpmc_ecx_to_pmc)(struct kvm_vcpu vcpu,\n \t\tunsigned int idx, u64 mask);\ndiff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c\nindex afcac1042947a5..cc8a36f28aea98 100644\n--- a/arch/x86/kvm/x86.c\n+++ b/arch/x86/kvm/x86.c\n@@ -4964,6 +4964,9 @@ int kvm_vm_ioctl_check_extension(struct kvm kvm, long ext)\n \tcase KVM_CAP_DISABLE_QUIRKS2:\n \t\tr = kvm_caps.supported_quirks;\n \t\tbreak;\n+\tcase KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING:\n+\t\tr = KVM_PMU_SW_ACCOUNTING_VALID_MASK;\n+\t\tbreak;\n \tcase KVM_CAP_X86_NOTIFY_VMEXIT:\n \t\tr = kvm_caps.has_notify_vmexit;\n \t\tbreak;\n@@ -6730,6 +6733,18 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,\n \t\treturn -EINVAL;\n \n \tswitch (cap-\u003ecap) {\n+\tcase KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING:\n+\t\tr = -EINVAL;\n+\t\tif (cap-\u003eargs[0] \u0026 ~KVM_PMU_SW_ACCOUNTING_VALID_MASK)\n+\t\t\tbreak;\n+\n+\t\tmutex_lock(\u0026kvm-\u003elock);\n+\t\tif (!kvm-\u003ecreated_vcpus) {\n+\t\t\tkvm-\u003earch.pmu_disable_sw_accounting = cap-\u003eargs[0];\n+\t\t\tr = 0;\n+\t\t}\n+\t\tmutex_unlock(\u0026kvm-\u003elock);\n+\t\tbreak;\n \tcase KVM_CAP_DISABLE_QUIRKS2:\n \t\tr = -EINVAL;\n \t\tif (cap-\u003eargs[0] \u0026 ~kvm_caps.supported_quirks)\ndiff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h\nindex 419011097fa8e2..186054245b80ea 100644\n--- a/include/uapi/linux/kvm.h\n+++ b/include/uapi/linux/kvm.h\n@@ -997,6 +997,7 @@ struct kvm_enable_cap {\n #define KVM_CAP_S390_KEYOP 247\n #define KVM_CAP_S390_VSIE_ESAMODE 248\n #define KVM_CAP_S390_HPAGE_2G 249\n+#define KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING 250\n \n struct kvm_irq_routing_irqchip {\n \t__u32 irqchip;\n" }
2/1	2026/07/21 03:47	agent	patch-evaluator	0m Model: best-expensive Args: null Results: { "EnableConfigs": [ "KVM" ], "FocusSymbols": [ "kvm_pmu_instruction_retired", "kvm_pmu_branch_retired" ], "Reasoning": "This patch introduces a new KVM capability `KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING` that alters the behavior of software accounting for KVM-emulated instructions. It modifies core KVM PMU logic and should be fuzzed to ensure the capability is handled correctly and doesn't introduce regressions or vulnerabilities.", "WorthFuzzing": true } Instruction: You are an expert Linux kernel maintainer. Your job is to review a provided patch series and determine if it makes functional changes to the kernel that should be fuzzed. IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively use your code access tools to examine the actual source code and confirm any assumptions. Return WorthFuzzing=false if the patch only contains: - Modifications to Documentation/, Kconfig files, or code comments. - Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints. - Changes to numeric constants or macros that do not functionally alter execution flow. - Code paths that are impossible to reach in virtualized environments like GCE or QEMU, even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim). If it modifies reachable core kernel logic, drivers, or architectures, use your code search tools to verify the code can be executed, then return WorthFuzzing=true. When returning WorthFuzzing=true, you MUST ALSO: 1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols. Avoid listing generic hot-path functions to prevent skewed test distributions. 2. Identify any specific CONFIG_ options required to properly test this new/modified feature. Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions. Do not list too generic configs (we already have them enabled). Only list those that specifically cover the modified code. List them in the EnableConfigs output array, and DO NOT add a '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: For your convenience, here is the diff of the changes: commit a1efd12e06a5471be739c918a04e81b6ea095605 Author: syz-cluster <triage@syzkaller.com> Date: Tue Jul 21 03:47:35 2026 +0000 syz-cluster: applied patch under review diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index a5f9ee92f43e8d..231a5ba7567c51 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -8949,6 +8949,38 @@ enabled, cmma can't be enabled anymore and pfmfi and the storage key interpretation are disabled. If cmma has already been enabled or the hpage_2g module parameter is not set to 1, -EINVAL is returned. +7.48 KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING +------------------------------------------ + +:Architectures: x86 +:Type: vm +:Parameters: args[0] - bitmask of PERF_COUNT_HW_* event IDs +:Returns: 0 on success; -EINVAL if args[0] contains an unsupported event or + if the VM already has vCPUs. + +By default, KVM software-accounts instructions it emulates against a guest +PMU counter programmed for retired instructions (PERF_COUNT_HW_INSTRUCTIONS) +or retired branches (PERF_COUNT_HW_BRANCH_INSTRUCTIONS), by walking the vPMU +counters and requesting a counter reprogram on the next VM-entry. On hosts +with an emulated vPMU this reprogram is expensive and, under some workloads, +inflates timer-interrupt handling enough to trigger guest CSD lockups. + +This capability lets userspace disable that software accounting for the given +events. Setting a bit for an event ID makes KVM skip the accounting for that +event: instructions KVM emulates in host context go uncounted. Hardware- +executed guest instructions are still counted by the backing perf_event, and +its overflow/PMI path is unaffected. + +The capability only affects the emulated (perf-based) vPMU. A mediated vPMU +does not incur the reprogram cost and increments the guest counter directly, +so accounting is never skipped for it regardless of this setting. + +This can only be invoked on a VM prior to the creation of vCPUs; attempting to +set it once any vCPU exists returns -EINVAL. + +KVM_CHECK_EXTENSION returns the bitmask of event IDs that can be disabled. +args[0] must be a subset of that mask. + 8. Other capabilities. ====================== diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 5f6c1ce9673b7f..522f66c44e6a00 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1560,6 +1560,13 @@ struct kvm_arch { bool enable_pmu; bool created_mediated_pmu; + /* + * Bitmask of PERF_COUNT_HW_* event IDs for which software accounting + * of KVM-emulated instructions is disabled (KVM_CAP_X86_DISABLE_PMU_ + * SW_ACCOUNTING). See kvm_pmu_trigger_event(). + / + u64 pmu_disable_sw_accounting; + u32 notify_window; u32 notify_vmexit_flags; / diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c index dd1c57593f48b8..fb3f2df068dc47 100644 --- a/arch/x86/kvm/pmu.c +++ b/arch/x86/kvm/pmu.c @@ -1145,14 +1145,35 @@ static void kvm_pmu_trigger_event(struct kvm_vcpu vcpu, srcu_read_unlock(&vcpu->kvm->srcu, idx); } +/ + * Whether software accounting of KVM-emulated instructions for @perf_hw_id is + * disabled via KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING. The capability only + * targets the emulated (perf-based) vPMU, where the accounting drives an + * expensive counter reprogram; a mediated vPMU increments pmc->counter + * directly (and may raise a PMI on overflow), so it is never skipped. + / +static bool kvm_pmu_skip_sw_accounting(struct kvm_vcpu vcpu, u64 perf_hw_id) +{ + if (kvm_vcpu_has_mediated_pmu(vcpu)) + return false; + + return vcpu->kvm->arch.pmu_disable_sw_accounting & BIT_ULL(perf_hw_id); +} + void kvm_pmu_instruction_retired(struct kvm_vcpu vcpu) { + if (kvm_pmu_skip_sw_accounting(vcpu, PERF_COUNT_HW_INSTRUCTIONS)) + return; + kvm_pmu_trigger_event(vcpu, vcpu_to_pmu(vcpu)->pmc_counting_instructions); } EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_pmu_instruction_retired); void kvm_pmu_branch_retired(struct kvm_vcpu vcpu) { + if (kvm_pmu_skip_sw_accounting(vcpu, PERF_COUNT_HW_BRANCH_INSTRUCTIONS)) + return; + kvm_pmu_trigger_event(vcpu, vcpu_to_pmu(vcpu)->pmc_counting_branches); } EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_pmu_branch_retired); diff --git a/arch/x86/kvm/pmu.h b/arch/x86/kvm/pmu.h index a5821d7c87f935..e34b9e81435557 100644 --- a/arch/x86/kvm/pmu.h +++ b/arch/x86/kvm/pmu.h @@ -23,6 +23,15 @@ #define KVM_FIXED_PMC_BASE_IDX INTEL_PMC_IDX_FIXED +/* + * Events for which KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING can disable software + * accounting of emulated instructions. These are the only events KVM ever + * passes to kvm_pmu_trigger_event() (from the retired-instruction path). + / +#define KVM_PMU_SW_ACCOUNTING_VALID_MASK \ + (BIT_ULL(PERF_COUNT_HW_INSTRUCTIONS) \| \ + BIT_ULL(PERF_COUNT_HW_BRANCH_INSTRUCTIONS)) + struct kvm_pmu_ops { struct kvm_pmc (rdpmc_ecx_to_pmc)(struct kvm_vcpu vcpu, unsigned int idx, u64 mask); diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index afcac1042947a5..cc8a36f28aea98 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -4964,6 +4964,9 @@ int kvm_vm_ioctl_check_extension(struct kvm kvm, long ext) case KVM_CAP_DISABLE_QUIRKS2: r = kvm_caps.supported_quirks; break; + case KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING: + r = KVM_PMU_SW_ACCOUNTING_VALID_MASK; + break; case KVM_CAP_X86_NOTIFY_VMEXIT: r = kvm_caps.has_notify_vmexit; break; @@ -6730,6 +6733,18 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, return -EINVAL; switch (cap->cap) { + case KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING: + r = -EINVAL; + if (cap->args[0] & ~KVM_PMU_SW_ACCOUNTING_VALID_MASK) + break; + + mutex_lock(&kvm->lock); + if (!kvm->created_vcpus) { + kvm->arch.pmu_disable_sw_accounting = cap->args[0]; + r = 0; + } + mutex_unlock(&kvm->lock); + break; case KVM_CAP_DISABLE_QUIRKS2: r = -EINVAL; if (cap->args[0] & ~kvm_caps.supported_quirks) diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 419011097fa8e2..186054245b80ea 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -997,6 +997,7 @@ struct kvm_enable_cap { #define KVM_CAP_S390_KEYOP 247 #define KVM_CAP_S390_VSIE_ESAMODE 248 #define KVM_CAP_S390_HPAGE_2G 249 +#define KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING 250 struct kvm_irq_routing_irqchip { __u32 irqchip;
3/2	2026/07/21 03:47	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 4289 output: 23 thoughts: 365 Thoughts: My Assessment of the KVM PMU Software Accounting Patch Okay, so I'm looking at this patch introducing `KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING` (250). It looks like they're giving userspace the ability to disable the software-based accounting of instructions within KVM, specifically for the `PERF_COUNT_HW_INSTRUCTIONS` and `PERF_COUNT_HW_BRANCH_INSTRUCTIONS` events. That's a reasonable request, especially in performance-sensitive scenarios or where userspace wants very fine-grained control over the performance data it's collecting. They've modified `arch/x86/kvm/pmu.c` and `arch/x86/kvm/x86.c`, and they've added a `pmu_disable_sw_accounting` field to the `struct kvm_arch`. Makes sense – a clean way to store the disabling state. The core of the change seems to be in `kvm_pmu_instruction_retired` and `kvm_pmu_branch_retired`. Essentially, the patch is adding a check in these functions. If the capability bit is set, it bypasses the `kvm_pmu_trigger_event` call, which is where the accounting would happen. So, they're avoiding the overhead of triggering those events. This is definitely a functional change to the KVM x86 subsystem. That means this needs some serious fuzzing. Gotta check for any edge cases or unexpected behavior when this accounting is disabled. Let's see, what are the key symbols? Looks like the primary focus should be `kvm_pmu_instruction_retired`, `kvm_pmu_branch_retired`, and maybe `kvm_pmu_skip_sw_accounting`, even though that one is static and might be inlined. I’m going to consider `kvm_vm_ioctl_enable_cap` but it seems pretty generic, so it might not be a target. Wait, looking at `kvm_pmu_instruction_retired` and `kvm_pmu_branch_retired`, they are being called when instructions are retired. Crucially, `kvm_pmu_instruction_retired` is called when KVM is emulating an instruction, which may be more frequent than instruction retirement. Let me double check where those are being called. That's the critical path to examine.
4/2	2026/07/21 03:47	tool	grepper	0m Args: { "Expression": "kvm_pmu_instruction_retired" } Results: { "Output": "arch/x86/kvm/pmu.c=1155=static bool kvm_pmu_skip_sw_accounting(struct kvm_vcpu vcpu, u64 perf_hw_id)\n--\narch/x86/kvm/pmu.c-1162-\narch/x86/kvm/pmu.c:1163:void kvm_pmu_instruction_retired(struct kvm_vcpu vcpu)\narch/x86/kvm/pmu.c-1164-{\n--\narch/x86/kvm/pmu.c-1169-}\narch/x86/kvm/pmu.c:1170:EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_pmu_instruction_retired);\narch/x86/kvm/pmu.c-1171-\n--\narch/x86/kvm/pmu.h=293=int kvm_vm_ioctl_set_pmu_event_filter(struct kvm kvm, void __user argp);\narch/x86/kvm/pmu.h:294:void kvm_pmu_instruction_retired(struct kvm_vcpu vcpu);\narch/x86/kvm/pmu.h-295-void kvm_pmu_branch_retired(struct kvm_vcpu vcpu);\n--\narch/x86/kvm/svm/nested.c=1114=int nested_svm_vmrun(struct kvm_vcpu vcpu)\n--\narch/x86/kvm/svm/nested.c-1197-\t /\narch/x86/kvm/svm/nested.c:1198:\tkvm_pmu_instruction_retired(vcpu);\narch/x86/kvm/svm/nested.c-1199-\treturn 1;\n--\narch/x86/kvm/x86.c=9278=int kvm_skip_emulated_instruction(struct kvm_vcpu vcpu)\n--\narch/x86/kvm/x86.c-9286-\narch/x86/kvm/x86.c:9287:\tkvm_pmu_instruction_retired(vcpu);\narch/x86/kvm/x86.c-9288-\n--\narch/x86/kvm/x86.c=9436=int x86_emulate_instruction(struct kvm_vcpu vcpu, gpa_t cr2_or_gpa,\n--\narch/x86/kvm/x86.c-9631-\t\t exception_type(ctxt-\u003eexception.vector) == EXCPT_TRAP) {\narch/x86/kvm/x86.c:9632:\t\t\tkvm_pmu_instruction_retired(vcpu);\narch/x86/kvm/x86.c-9633-\t\t\tif (ctxt-\u003eis_branch)\n" }
5/2	2026/07/21 03:47	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 5989 output: 23 thoughts: 79 Thoughts: Okay, here's my take on those thoughts, framed as my own: Analyzing KVM Performance Counters Right, so I'm thinking about performance monitoring in KVM again, and `kvm_pmu_instruction_retired` and `kvm_pmu_branch_retired` are definitely key focus points. Those are solid symbols to hone in on. And then I recall that `kvm_vm_ioctl_enable_cap` gets its hands dirty with `KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING` which is also relevant. Gotta keep those interrelated. Let's dig into `kvm_pmu_branch_retired`. I want to see what's happening there.
6/2	2026/07/21 03:47	tool	grepper	0m Args: { "Expression": "kvm_pmu_branch_retired" } Results: { "Output": "arch/x86/kvm/pmu.c=1170=EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_pmu_instruction_retired);\narch/x86/kvm/pmu.c-1171-\narch/x86/kvm/pmu.c:1172:void kvm_pmu_branch_retired(struct kvm_vcpu vcpu)\narch/x86/kvm/pmu.c-1173-{\n--\narch/x86/kvm/pmu.c-1178-}\narch/x86/kvm/pmu.c:1179:EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_pmu_branch_retired);\narch/x86/kvm/pmu.c-1180-\n--\narch/x86/kvm/pmu.h=294=void kvm_pmu_instruction_retired(struct kvm_vcpu vcpu);\narch/x86/kvm/pmu.h:295:void kvm_pmu_branch_retired(struct kvm_vcpu vcpu);\narch/x86/kvm/pmu.h-296-void kvm_mediated_pmu_load(struct kvm_vcpu vcpu);\n--\narch/x86/kvm/vmx/nested.c=3777=static int nested_vmx_run(struct kvm_vcpu vcpu, bool launch)\n--\narch/x86/kvm/vmx/nested.c-3793-\narch/x86/kvm/vmx/nested.c:3794:\tkvm_pmu_branch_retired(vcpu);\narch/x86/kvm/vmx/nested.c-3795-\n--\narch/x86/kvm/x86.c=9436=int x86_emulate_instruction(struct kvm_vcpu vcpu, gpa_t cr2_or_gpa,\n--\narch/x86/kvm/x86.c-9633-\t\t\tif (ctxt-\u003eis_branch)\narch/x86/kvm/x86.c:9634:\t\t\t\tkvm_pmu_branch_retired(vcpu);\narch/x86/kvm/x86.c-9635-\t\t\tkvm_rip_write(vcpu, ctxt-\u003eeip);\n" }
7/2	2026/07/21 03:47	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 6876 output: 34 thoughts: 10 Thoughts: Okay, here's my summarized thought process, presented as if I'm thinking it: Checking Kconfig for KVM Alright, time to get started. My initial thought is to make sure I haven't missed anything crucial regarding KVM configuration. The first port of call, naturally, is the Kconfig files. I need to quickly and methodically confirm that all relevant KVM options are enabled or, at least, correctly handled within the kernel build configuration. I'll need to double-check dependencies, default settings, and any potential conflicts with other features that might impact KVM's performance or functionality. This quick audit will hopefully prevent any needless debugging later on. Let's dig in and make sure everything is as it should be.
8/2	2026/07/21 03:47	tool	grepper	0m Args: { "Expression": "config KVM", "PathPrefix": "arch/x86/kvm/Kconfig" } 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-171-\narch/x86/kvm/Kconfig:172:config KVM_IOAPIC\narch/x86/kvm/Kconfig-173-\tbool \"I/O APIC, PIC, and PIT emulation\"\n--\narch/x86/kvm/Kconfig-181-\narch/x86/kvm/Kconfig:182:config KVM_SMM\narch/x86/kvm/Kconfig-183-\tbool \"System Management Mode emulation\"\n--\narch/x86/kvm/Kconfig-192-\narch/x86/kvm/Kconfig:193:config KVM_HYPERV\narch/x86/kvm/Kconfig-194-\tbool \"Support for Microsoft Hyper-V emulation\"\n--\narch/x86/kvm/Kconfig-206-\narch/x86/kvm/Kconfig:207:config KVM_XEN\narch/x86/kvm/Kconfig-208-\tbool \"Support for Xen hypercall interface\"\n--\narch/x86/kvm/Kconfig-215-\narch/x86/kvm/Kconfig:216:config KVM_PROVE_MMU\narch/x86/kvm/Kconfig-217-\tbool \"Prove KVM MMU correctness\"\n--\narch/x86/kvm/Kconfig-228-\narch/x86/kvm/Kconfig:229:config KVM_EXTERNAL_WRITE_TRACKING\narch/x86/kvm/Kconfig-230-\tbool\narch/x86/kvm/Kconfig-231-\narch/x86/kvm/Kconfig:232:config KVM_MAX_NR_VCPUS\narch/x86/kvm/Kconfig-233-\tint \"Maximum number of vCPUs per KVM guest\"\n" }
9/2	2026/07/21 03:47	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 8293 output: 131 thoughts: 252 Thoughts: My Analysis of the KVM PMU Software Accounting Patch Okay, so I've been looking at this new patch related to the KVM PMU and its software accounting. The key configurations are `KVM` and `KVM_X86`. My initial thought is to zero in on the relevant symbols; that's where I need to focus my fuzzing efforts. I've identified the focus symbols: `kvm_pmu_instruction_retired`, `kvm_pmu_branch_retired`, and `kvm_pmu_skip_sw_accounting`. I need to confirm if `kvm_pmu_skip_sw_accounting` is a static variable, and yes, I've confirmed it's static within `arch/x86/kvm/pmu.c`. Based on this, it's probably less critical for direct fuzzing. Therefore, I'll prioritize `kvm_pmu_instruction_retired` and `kvm_pmu_branch_retired` as the primary targets. Given the potential impact on core KVM PMU logic introduced by `KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING`, I've decided this definitely warrants fuzzing. I'll set my internal flag, `WorthFuzzing`, to true. Therefore, the key configurations I'll use in my fuzzing campaign will be `KVM`, and I will target the symbols `kvm_pmu_instruction_retired` and `kvm_pmu_branch_retired`. I need to ensure the new capability is handled correctly. I also want to prevent regressions or vulnerabilities. This looks like a solid starting point for fuzzing this patch.
10/2	2026/07/21 03:47	tool	set-results	0m Args: { "EnableConfigs": [ "KVM" ], "FocusSymbols": [ "kvm_pmu_instruction_retired", "kvm_pmu_branch_retired" ], "Reasoning": "This patch introduces a new KVM capability `KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING` that alters the behavior of software accounting for KVM-emulated instructions. It modifies core KVM PMU logic and should be fuzzed to ensure the capability is handled correctly and doesn't introduce regressions or vulnerabilities.", "WorthFuzzing": true } Results: { "EnableConfigs": [ "KVM" ], "FocusSymbols": [ "kvm_pmu_instruction_retired", "kvm_pmu_branch_retired" ], "Reasoning": "This patch introduces a new KVM capability `KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING` that alters the behavior of software accounting for KVM-emulated instructions. It modifies core KVM PMU logic and should be fuzzed to ensure the capability is handled correctly and doesn't introduce regressions or vulnerabilities.", "WorthFuzzing": true }

{
  "EnableConfigs": [
    "KVM"
  ],
  "FocusSymbols": [
    "kvm_pmu_instruction_retired",
    "kvm_pmu_branch_retired"
  ],
  "Reasoning": "This patch introduces a new KVM capability `KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING` that alters the behavior of software accounting for KVM-emulated instructions. It modifies core KVM PMU logic and should be fuzzed to ensure the capability is handled correctly and doesn't introduce regressions or vulnerabilities.",
  "WorthFuzzing": true
}

{
  "PatchDiff": "commit a1efd12e06a5471be739c918a04e81b6ea095605\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Tue Jul 21 03:47:35 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 a5f9ee92f43e8d..231a5ba7567c51 100644\n--- a/Documentation/virt/kvm/api.rst\n+++ b/Documentation/virt/kvm/api.rst\n@@ -8949,6 +8949,38 @@ enabled, cmma can't be enabled anymore and pfmfi and the storage key\n interpretation are disabled. If cmma has already been enabled or the\n hpage_2g module parameter is not set to 1, -EINVAL is returned.\n \n+7.48 KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING\n+------------------------------------------\n+\n+:Architectures: x86\n+:Type: vm\n+:Parameters: args[0] - bitmask of PERF_COUNT_HW_* event IDs\n+:Returns: 0 on success; -EINVAL if args[0] contains an unsupported event or\n+          if the VM already has vCPUs.\n+\n+By default, KVM software-accounts instructions it emulates against a guest\n+PMU counter programmed for retired instructions (PERF_COUNT_HW_INSTRUCTIONS)\n+or retired branches (PERF_COUNT_HW_BRANCH_INSTRUCTIONS), by walking the vPMU\n+counters and requesting a counter reprogram on the next VM-entry. On hosts\n+with an emulated vPMU this reprogram is expensive and, under some workloads,\n+inflates timer-interrupt handling enough to trigger guest CSD lockups.\n+\n+This capability lets userspace disable that software accounting for the given\n+events. Setting a bit for an event ID makes KVM skip the accounting for that\n+event: instructions KVM emulates in host context go uncounted. Hardware-\n+executed guest instructions are still counted by the backing perf_event, and\n+its overflow/PMI path is unaffected.\n+\n+The capability only affects the emulated (perf-based) vPMU. A mediated vPMU\n+does not incur the reprogram cost and increments the guest counter directly,\n+so accounting is never skipped for it regardless of this setting.\n+\n+This can only be invoked on a VM prior to the creation of vCPUs; attempting to\n+set it once any vCPU exists returns -EINVAL.\n+\n+KVM_CHECK_EXTENSION returns the bitmask of event IDs that can be disabled.\n+args[0] must be a subset of that mask.\n+\n 8. Other capabilities.\n ======================\n \ndiff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h\nindex 5f6c1ce9673b7f..522f66c44e6a00 100644\n--- a/arch/x86/include/asm/kvm_host.h\n+++ b/arch/x86/include/asm/kvm_host.h\n@@ -1560,6 +1560,13 @@ struct kvm_arch {\n \tbool enable_pmu;\n \tbool created_mediated_pmu;\n \n+\t/*\n+\t * Bitmask of PERF_COUNT_HW_* event IDs for which software accounting\n+\t * of KVM-emulated instructions is disabled (KVM_CAP_X86_DISABLE_PMU_\n+\t * SW_ACCOUNTING). See kvm_pmu_trigger_event().\n+\t */\n+\tu64 pmu_disable_sw_accounting;\n+\n \tu32 notify_window;\n \tu32 notify_vmexit_flags;\n \t/*\ndiff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c\nindex dd1c57593f48b8..fb3f2df068dc47 100644\n--- a/arch/x86/kvm/pmu.c\n+++ b/arch/x86/kvm/pmu.c\n@@ -1145,14 +1145,35 @@ static void kvm_pmu_trigger_event(struct kvm_vcpu *vcpu,\n \tsrcu_read_unlock(\u0026vcpu-\u003ekvm-\u003esrcu, idx);\n }\n \n+/*\n+ * Whether software accounting of KVM-emulated instructions for @perf_hw_id is\n+ * disabled via KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING. The capability only\n+ * targets the emulated (perf-based) vPMU, where the accounting drives an\n+ * expensive counter reprogram; a mediated vPMU increments pmc-\u003ecounter\n+ * directly (and may raise a PMI on overflow), so it is never skipped.\n+ */\n+static bool kvm_pmu_skip_sw_accounting(struct kvm_vcpu *vcpu, u64 perf_hw_id)\n+{\n+\tif (kvm_vcpu_has_mediated_pmu(vcpu))\n+\t\treturn false;\n+\n+\treturn vcpu-\u003ekvm-\u003earch.pmu_disable_sw_accounting \u0026 BIT_ULL(perf_hw_id);\n+}\n+\n void kvm_pmu_instruction_retired(struct kvm_vcpu *vcpu)\n {\n+\tif (kvm_pmu_skip_sw_accounting(vcpu, PERF_COUNT_HW_INSTRUCTIONS))\n+\t\treturn;\n+\n \tkvm_pmu_trigger_event(vcpu, vcpu_to_pmu(vcpu)-\u003epmc_counting_instructions);\n }\n EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_pmu_instruction_retired);\n \n void kvm_pmu_branch_retired(struct kvm_vcpu *vcpu)\n {\n+\tif (kvm_pmu_skip_sw_accounting(vcpu, PERF_COUNT_HW_BRANCH_INSTRUCTIONS))\n+\t\treturn;\n+\n \tkvm_pmu_trigger_event(vcpu, vcpu_to_pmu(vcpu)-\u003epmc_counting_branches);\n }\n EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_pmu_branch_retired);\ndiff --git a/arch/x86/kvm/pmu.h b/arch/x86/kvm/pmu.h\nindex a5821d7c87f935..e34b9e81435557 100644\n--- a/arch/x86/kvm/pmu.h\n+++ b/arch/x86/kvm/pmu.h\n@@ -23,6 +23,15 @@\n \n #define KVM_FIXED_PMC_BASE_IDX INTEL_PMC_IDX_FIXED\n \n+/*\n+ * Events for which KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING can disable software\n+ * accounting of emulated instructions. These are the only events KVM ever\n+ * passes to kvm_pmu_trigger_event() (from the retired-instruction path).\n+ */\n+#define KVM_PMU_SW_ACCOUNTING_VALID_MASK\t\t\t\\\n+\t(BIT_ULL(PERF_COUNT_HW_INSTRUCTIONS) |\t\t\t\\\n+\t BIT_ULL(PERF_COUNT_HW_BRANCH_INSTRUCTIONS))\n+\n struct kvm_pmu_ops {\n \tstruct kvm_pmc *(*rdpmc_ecx_to_pmc)(struct kvm_vcpu *vcpu,\n \t\tunsigned int idx, u64 *mask);\ndiff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c\nindex afcac1042947a5..cc8a36f28aea98 100644\n--- a/arch/x86/kvm/x86.c\n+++ b/arch/x86/kvm/x86.c\n@@ -4964,6 +4964,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)\n \tcase KVM_CAP_DISABLE_QUIRKS2:\n \t\tr = kvm_caps.supported_quirks;\n \t\tbreak;\n+\tcase KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING:\n+\t\tr = KVM_PMU_SW_ACCOUNTING_VALID_MASK;\n+\t\tbreak;\n \tcase KVM_CAP_X86_NOTIFY_VMEXIT:\n \t\tr = kvm_caps.has_notify_vmexit;\n \t\tbreak;\n@@ -6730,6 +6733,18 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,\n \t\treturn -EINVAL;\n \n \tswitch (cap-\u003ecap) {\n+\tcase KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING:\n+\t\tr = -EINVAL;\n+\t\tif (cap-\u003eargs[0] \u0026 ~KVM_PMU_SW_ACCOUNTING_VALID_MASK)\n+\t\t\tbreak;\n+\n+\t\tmutex_lock(\u0026kvm-\u003elock);\n+\t\tif (!kvm-\u003ecreated_vcpus) {\n+\t\t\tkvm-\u003earch.pmu_disable_sw_accounting = cap-\u003eargs[0];\n+\t\t\tr = 0;\n+\t\t}\n+\t\tmutex_unlock(\u0026kvm-\u003elock);\n+\t\tbreak;\n \tcase KVM_CAP_DISABLE_QUIRKS2:\n \t\tr = -EINVAL;\n \t\tif (cap-\u003eargs[0] \u0026 ~kvm_caps.supported_quirks)\ndiff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h\nindex 419011097fa8e2..186054245b80ea 100644\n--- a/include/uapi/linux/kvm.h\n+++ b/include/uapi/linux/kvm.h\n@@ -997,6 +997,7 @@ struct kvm_enable_cap {\n #define KVM_CAP_S390_KEYOP 247\n #define KVM_CAP_S390_VSIE_ESAMODE 248\n #define KVM_CAP_S390_HPAGE_2G 249\n+#define KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING 250\n \n struct kvm_irq_routing_irqchip {\n \t__u32 irqchip;\n"
}

{
  "EnableConfigs": [
    "KVM"
  ],
  "FocusSymbols": [
    "kvm_pmu_instruction_retired",
    "kvm_pmu_branch_retired"
  ],
  "Reasoning": "This patch introduces a new KVM capability `KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING` that alters the behavior of software accounting for KVM-emulated instructions. It modifies core KVM PMU logic and should be fuzzed to ensure the capability is handled correctly and doesn't introduce regressions or vulnerabilities.",
  "WorthFuzzing": true
}

You are an expert Linux kernel maintainer.
Your job is to review a provided patch series and determine
if it makes functional changes to the kernel that should be fuzzed.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively
use your code access tools to examine the actual source code and confirm any assumptions.

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).

If it modifies reachable core kernel logic, drivers, or architectures, use your code search
tools to verify the code can be executed, then return WorthFuzzing=true.

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Do not list too generic configs (we already have them enabled). Only list those that
   specifically cover the modified code. List them in the EnableConfigs output array,
   and DO NOT add a '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.

For your convenience, here is the diff of the changes:
commit a1efd12e06a5471be739c918a04e81b6ea095605
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Jul 21 03:47:35 2026 +0000

    syz-cluster: applied patch under review

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index a5f9ee92f43e8d..231a5ba7567c51 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -8949,6 +8949,38 @@ enabled, cmma can't be enabled anymore and pfmfi and the storage key
 interpretation are disabled. If cmma has already been enabled or the
 hpage_2g module parameter is not set to 1, -EINVAL is returned.
 
+7.48 KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING
+------------------------------------------
+
+:Architectures: x86
+:Type: vm
+:Parameters: args[0] - bitmask of PERF_COUNT_HW_* event IDs
+:Returns: 0 on success; -EINVAL if args[0] contains an unsupported event or
+          if the VM already has vCPUs.
+
+By default, KVM software-accounts instructions it emulates against a guest
+PMU counter programmed for retired instructions (PERF_COUNT_HW_INSTRUCTIONS)
+or retired branches (PERF_COUNT_HW_BRANCH_INSTRUCTIONS), by walking the vPMU
+counters and requesting a counter reprogram on the next VM-entry. On hosts
+with an emulated vPMU this reprogram is expensive and, under some workloads,
+inflates timer-interrupt handling enough to trigger guest CSD lockups.
+
+This capability lets userspace disable that software accounting for the given
+events. Setting a bit for an event ID makes KVM skip the accounting for that
+event: instructions KVM emulates in host context go uncounted. Hardware-
+executed guest instructions are still counted by the backing perf_event, and
+its overflow/PMI path is unaffected.
+
+The capability only affects the emulated (perf-based) vPMU. A mediated vPMU
+does not incur the reprogram cost and increments the guest counter directly,
+so accounting is never skipped for it regardless of this setting.
+
+This can only be invoked on a VM prior to the creation of vCPUs; attempting to
+set it once any vCPU exists returns -EINVAL.
+
+KVM_CHECK_EXTENSION returns the bitmask of event IDs that can be disabled.
+args[0] must be a subset of that mask.
+
 8. Other capabilities.
 ======================
 
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 5f6c1ce9673b7f..522f66c44e6a00 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1560,6 +1560,13 @@ struct kvm_arch {
 	bool enable_pmu;
 	bool created_mediated_pmu;
 
+	/*
+	 * Bitmask of PERF_COUNT_HW_* event IDs for which software accounting
+	 * of KVM-emulated instructions is disabled (KVM_CAP_X86_DISABLE_PMU_
+	 * SW_ACCOUNTING). See kvm_pmu_trigger_event().
+	 */
+	u64 pmu_disable_sw_accounting;
+
 	u32 notify_window;
 	u32 notify_vmexit_flags;
 	/*
diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index dd1c57593f48b8..fb3f2df068dc47 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -1145,14 +1145,35 @@ static void kvm_pmu_trigger_event(struct kvm_vcpu *vcpu,
 	srcu_read_unlock(&vcpu->kvm->srcu, idx);
 }
 
+/*
+ * Whether software accounting of KVM-emulated instructions for @perf_hw_id is
+ * disabled via KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING. The capability only
+ * targets the emulated (perf-based) vPMU, where the accounting drives an
+ * expensive counter reprogram; a mediated vPMU increments pmc->counter
+ * directly (and may raise a PMI on overflow), so it is never skipped.
+ */
+static bool kvm_pmu_skip_sw_accounting(struct kvm_vcpu *vcpu, u64 perf_hw_id)
+{
+	if (kvm_vcpu_has_mediated_pmu(vcpu))
+		return false;
+
+	return vcpu->kvm->arch.pmu_disable_sw_accounting & BIT_ULL(perf_hw_id);
+}
+
 void kvm_pmu_instruction_retired(struct kvm_vcpu *vcpu)
 {
+	if (kvm_pmu_skip_sw_accounting(vcpu, PERF_COUNT_HW_INSTRUCTIONS))
+		return;
+
 	kvm_pmu_trigger_event(vcpu, vcpu_to_pmu(vcpu)->pmc_counting_instructions);
 }
 EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_pmu_instruction_retired);
 
 void kvm_pmu_branch_retired(struct kvm_vcpu *vcpu)
 {
+	if (kvm_pmu_skip_sw_accounting(vcpu, PERF_COUNT_HW_BRANCH_INSTRUCTIONS))
+		return;
+
 	kvm_pmu_trigger_event(vcpu, vcpu_to_pmu(vcpu)->pmc_counting_branches);
 }
 EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_pmu_branch_retired);
diff --git a/arch/x86/kvm/pmu.h b/arch/x86/kvm/pmu.h
index a5821d7c87f935..e34b9e81435557 100644
--- a/arch/x86/kvm/pmu.h
+++ b/arch/x86/kvm/pmu.h
@@ -23,6 +23,15 @@
 
 #define KVM_FIXED_PMC_BASE_IDX INTEL_PMC_IDX_FIXED
 
+/*
+ * Events for which KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING can disable software
+ * accounting of emulated instructions. These are the only events KVM ever
+ * passes to kvm_pmu_trigger_event() (from the retired-instruction path).
+ */
+#define KVM_PMU_SW_ACCOUNTING_VALID_MASK			\
+	(BIT_ULL(PERF_COUNT_HW_INSTRUCTIONS) |			\
+	 BIT_ULL(PERF_COUNT_HW_BRANCH_INSTRUCTIONS))
+
 struct kvm_pmu_ops {
 	struct kvm_pmc *(*rdpmc_ecx_to_pmc)(struct kvm_vcpu *vcpu,
 		unsigned int idx, u64 *mask);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index afcac1042947a5..cc8a36f28aea98 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4964,6 +4964,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
 	case KVM_CAP_DISABLE_QUIRKS2:
 		r = kvm_caps.supported_quirks;
 		break;
+	case KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING:
+		r = KVM_PMU_SW_ACCOUNTING_VALID_MASK;
+		break;
 	case KVM_CAP_X86_NOTIFY_VMEXIT:
 		r = kvm_caps.has_notify_vmexit;
 		break;
@@ -6730,6 +6733,18 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
 		return -EINVAL;
 
 	switch (cap->cap) {
+	case KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING:
+		r = -EINVAL;
+		if (cap->args[0] & ~KVM_PMU_SW_ACCOUNTING_VALID_MASK)
+			break;
+
+		mutex_lock(&kvm->lock);
+		if (!kvm->created_vcpus) {
+			kvm->arch.pmu_disable_sw_accounting = cap->args[0];
+			r = 0;
+		}
+		mutex_unlock(&kvm->lock);
+		break;
 	case KVM_CAP_DISABLE_QUIRKS2:
 		r = -EINVAL;
 		if (cap->args[0] & ~kvm_caps.supported_quirks)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 419011097fa8e2..186054245b80ea 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -997,6 +997,7 @@ struct kvm_enable_cap {
 #define KVM_CAP_S390_KEYOP 247
 #define KVM_CAP_S390_VSIE_ESAMODE 248
 #define KVM_CAP_S390_HPAGE_2G 249
+#define KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING 250
 
 struct kvm_irq_routing_irqchip {
 	__u32 irqchip;

gemini-3.1-pro-preview

							input: 4289
							output: 23
							thoughts: 365

**My Assessment of the KVM PMU Software Accounting Patch**

Okay, so I'm looking at this patch introducing `KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING` (250). It looks like they're giving userspace the ability to disable the software-based accounting of instructions within KVM, specifically for the `PERF_COUNT_HW_INSTRUCTIONS` and `PERF_COUNT_HW_BRANCH_INSTRUCTIONS` events. That's a reasonable request, especially in performance-sensitive scenarios or where userspace wants very fine-grained control over the performance data it's collecting.

They've modified `arch/x86/kvm/pmu.c` and `arch/x86/kvm/x86.c`, and they've added a `pmu_disable_sw_accounting` field to the `struct kvm_arch`. Makes sense – a clean way to store the disabling state.

The core of the change seems to be in `kvm_pmu_instruction_retired` and `kvm_pmu_branch_retired`.  Essentially, the patch is adding a check in these functions. If the capability bit is set, it bypasses the `kvm_pmu_trigger_event` call, which is where the accounting would happen. So, they're avoiding the overhead of triggering those events.

This is definitely a functional change to the KVM x86 subsystem. That means this needs some serious fuzzing. Gotta check for any edge cases or unexpected behavior when this accounting is disabled.

Let's see, what are the key symbols? Looks like the primary focus should be `kvm_pmu_instruction_retired`, `kvm_pmu_branch_retired`, and maybe `kvm_pmu_skip_sw_accounting`, even though that one is static and might be inlined. I’m going to consider `kvm_vm_ioctl_enable_cap` but it seems pretty generic, so it might not be a target.

Wait, looking at `kvm_pmu_instruction_retired` and `kvm_pmu_branch_retired`, they are being called when instructions are retired. Crucially, `kvm_pmu_instruction_retired` is called when KVM is *emulating* an instruction, which may be more frequent than instruction retirement. Let me double check where those are being called. That's the critical path to examine.

{
  "Expression": "kvm_pmu_instruction_retired"
}

{
  "Output": "arch/x86/kvm/pmu.c=1155=static bool kvm_pmu_skip_sw_accounting(struct kvm_vcpu *vcpu, u64 perf_hw_id)\n--\narch/x86/kvm/pmu.c-1162-\narch/x86/kvm/pmu.c:1163:void kvm_pmu_instruction_retired(struct kvm_vcpu *vcpu)\narch/x86/kvm/pmu.c-1164-{\n--\narch/x86/kvm/pmu.c-1169-}\narch/x86/kvm/pmu.c:1170:EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_pmu_instruction_retired);\narch/x86/kvm/pmu.c-1171-\n--\narch/x86/kvm/pmu.h=293=int kvm_vm_ioctl_set_pmu_event_filter(struct kvm *kvm, void __user *argp);\narch/x86/kvm/pmu.h:294:void kvm_pmu_instruction_retired(struct kvm_vcpu *vcpu);\narch/x86/kvm/pmu.h-295-void kvm_pmu_branch_retired(struct kvm_vcpu *vcpu);\n--\narch/x86/kvm/svm/nested.c=1114=int nested_svm_vmrun(struct kvm_vcpu *vcpu)\n--\narch/x86/kvm/svm/nested.c-1197-\t */\narch/x86/kvm/svm/nested.c:1198:\tkvm_pmu_instruction_retired(vcpu);\narch/x86/kvm/svm/nested.c-1199-\treturn 1;\n--\narch/x86/kvm/x86.c=9278=int kvm_skip_emulated_instruction(struct kvm_vcpu *vcpu)\n--\narch/x86/kvm/x86.c-9286-\narch/x86/kvm/x86.c:9287:\tkvm_pmu_instruction_retired(vcpu);\narch/x86/kvm/x86.c-9288-\n--\narch/x86/kvm/x86.c=9436=int x86_emulate_instruction(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa,\n--\narch/x86/kvm/x86.c-9631-\t\t    exception_type(ctxt-\u003eexception.vector) == EXCPT_TRAP) {\narch/x86/kvm/x86.c:9632:\t\t\tkvm_pmu_instruction_retired(vcpu);\narch/x86/kvm/x86.c-9633-\t\t\tif (ctxt-\u003eis_branch)\n"
}

gemini-3.1-pro-preview

							input: 5989
							output: 23
							thoughts: 79

Okay, here's my take on those thoughts, framed as my own:

**Analyzing KVM Performance Counters**

Right, so I'm thinking about performance monitoring in KVM again, and `kvm_pmu_instruction_retired` and `kvm_pmu_branch_retired` are definitely key focus points. Those are solid symbols to hone in on. And then I recall that `kvm_vm_ioctl_enable_cap` gets its hands dirty with `KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING` which is also relevant. Gotta keep those interrelated.

Let's dig into `kvm_pmu_branch_retired`. I want to see what's happening there.

{
  "Expression": "kvm_pmu_branch_retired"
}

{
  "Output": "arch/x86/kvm/pmu.c=1170=EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_pmu_instruction_retired);\narch/x86/kvm/pmu.c-1171-\narch/x86/kvm/pmu.c:1172:void kvm_pmu_branch_retired(struct kvm_vcpu *vcpu)\narch/x86/kvm/pmu.c-1173-{\n--\narch/x86/kvm/pmu.c-1178-}\narch/x86/kvm/pmu.c:1179:EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_pmu_branch_retired);\narch/x86/kvm/pmu.c-1180-\n--\narch/x86/kvm/pmu.h=294=void kvm_pmu_instruction_retired(struct kvm_vcpu *vcpu);\narch/x86/kvm/pmu.h:295:void kvm_pmu_branch_retired(struct kvm_vcpu *vcpu);\narch/x86/kvm/pmu.h-296-void kvm_mediated_pmu_load(struct kvm_vcpu *vcpu);\n--\narch/x86/kvm/vmx/nested.c=3777=static int nested_vmx_run(struct kvm_vcpu *vcpu, bool launch)\n--\narch/x86/kvm/vmx/nested.c-3793-\narch/x86/kvm/vmx/nested.c:3794:\tkvm_pmu_branch_retired(vcpu);\narch/x86/kvm/vmx/nested.c-3795-\n--\narch/x86/kvm/x86.c=9436=int x86_emulate_instruction(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa,\n--\narch/x86/kvm/x86.c-9633-\t\t\tif (ctxt-\u003eis_branch)\narch/x86/kvm/x86.c:9634:\t\t\t\tkvm_pmu_branch_retired(vcpu);\narch/x86/kvm/x86.c-9635-\t\t\tkvm_rip_write(vcpu, ctxt-\u003eeip);\n"
}

gemini-3.1-pro-preview

							input: 6876
							output: 34
							thoughts: 10

Okay, here's my summarized thought process, presented as if I'm thinking it:

**Checking Kconfig for KVM**

Alright, time to get started. My initial thought is to make sure I haven't missed anything crucial regarding KVM configuration. The first port of call, naturally, is the Kconfig files. I need to quickly and methodically confirm that all relevant KVM options are enabled or, at least, correctly handled within the kernel build configuration. I'll need to double-check dependencies, default settings, and any potential conflicts with other features that might impact KVM's performance or functionality. This quick audit will hopefully prevent any needless debugging later on. Let's dig in and make sure everything is as it should be.

{
  "Expression": "config KVM",
  "PathPrefix": "arch/x86/kvm/Kconfig"
}

{
  "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-171-\narch/x86/kvm/Kconfig:172:config KVM_IOAPIC\narch/x86/kvm/Kconfig-173-\tbool \"I/O APIC, PIC, and PIT emulation\"\n--\narch/x86/kvm/Kconfig-181-\narch/x86/kvm/Kconfig:182:config KVM_SMM\narch/x86/kvm/Kconfig-183-\tbool \"System Management Mode emulation\"\n--\narch/x86/kvm/Kconfig-192-\narch/x86/kvm/Kconfig:193:config KVM_HYPERV\narch/x86/kvm/Kconfig-194-\tbool \"Support for Microsoft Hyper-V emulation\"\n--\narch/x86/kvm/Kconfig-206-\narch/x86/kvm/Kconfig:207:config KVM_XEN\narch/x86/kvm/Kconfig-208-\tbool \"Support for Xen hypercall interface\"\n--\narch/x86/kvm/Kconfig-215-\narch/x86/kvm/Kconfig:216:config KVM_PROVE_MMU\narch/x86/kvm/Kconfig-217-\tbool \"Prove KVM MMU correctness\"\n--\narch/x86/kvm/Kconfig-228-\narch/x86/kvm/Kconfig:229:config KVM_EXTERNAL_WRITE_TRACKING\narch/x86/kvm/Kconfig-230-\tbool\narch/x86/kvm/Kconfig-231-\narch/x86/kvm/Kconfig:232:config KVM_MAX_NR_VCPUS\narch/x86/kvm/Kconfig-233-\tint \"Maximum number of vCPUs per KVM guest\"\n"
}

gemini-3.1-pro-preview

							input: 8293
							output: 131
							thoughts: 252

**My Analysis of the KVM PMU Software Accounting Patch**

Okay, so I've been looking at this new patch related to the KVM PMU and its software accounting. The key configurations are `KVM` and `KVM_X86`. My initial thought is to zero in on the relevant symbols; that's where I need to focus my fuzzing efforts. I've identified the focus symbols: `kvm_pmu_instruction_retired`, `kvm_pmu_branch_retired`, and `kvm_pmu_skip_sw_accounting`.

I need to confirm if `kvm_pmu_skip_sw_accounting` is a static variable, and yes, I've confirmed it's static within `arch/x86/kvm/pmu.c`. Based on this, it's probably less critical for direct fuzzing. Therefore, I'll prioritize `kvm_pmu_instruction_retired` and `kvm_pmu_branch_retired` as the primary targets.

Given the potential impact on core KVM PMU logic introduced by `KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING`, I've decided this definitely warrants fuzzing. I'll set my internal flag, `WorthFuzzing`, to true.

Therefore, the key configurations I'll use in my fuzzing campaign will be `KVM`, and I will target the symbols `kvm_pmu_instruction_retired` and `kvm_pmu_branch_retired`. I need to ensure the new capability is handled correctly. I also want to prevent regressions or vulnerabilities. This looks like a solid starting point for fuzzing this patch.

{
  "EnableConfigs": [
    "KVM"
  ],
  "FocusSymbols": [
    "kvm_pmu_instruction_retired",
    "kvm_pmu_branch_retired"
  ],
  "Reasoning": "This patch introduces a new KVM capability `KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING` that alters the behavior of software accounting for KVM-emulated instructions. It modifies core KVM PMU logic and should be fuzzed to ensure the capability is handled correctly and doesn't introduce regressions or vulnerabilities.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "KVM"
  ],
  "FocusSymbols": [
    "kvm_pmu_instruction_retired",
    "kvm_pmu_branch_retired"
  ],
  "Reasoning": "This patch introduces a new KVM capability `KVM_CAP_X86_DISABLE_PMU_SW_ACCOUNTING` that alters the behavior of software accounting for KVM-emulated instructions. It modifies core KVM PMU logic and should be fuzzed to ensure the capability is handled correctly and doesn't introduce regressions or vulnerabilities.",
  "WorthFuzzing": true
}

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)