| Seq | Timestamp | Type | Name | Duration |
|---|---|---|---|---|
| 0/0 | 2026/06/29 17:09 | flow | patch-triage |
0mArgs:null Results: {
"EnableConfigs": [
"KVM",
"KVM_XEN"
],
"FocusSymbols": [
"kvm_xen_vcpu_set_attr",
"__kvm_xen_write_hypercall_page"
],
"Reasoning": "The patch adds a new KVM Xen VCPU attribute `KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE` which allows userspace to trigger the population of the Xen hypercall page. This is reachable from userspace via the `KVM_XEN_VCPU_SET_ATTR` ioctl and modifies core KVM Xen emulation logic.",
"WorthFuzzing": true
} |
| 1/1 | 2026/06/29 17:09 | action | read-patch-diff |
0mArgs:null Results: {
"PatchDiff": "commit a4f79f499cea58c3c182ae88f9fcc55d174be17f\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Mon Jun 29 17:09:37 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..3c6aee2a35bfdc 100644\n--- a/Documentation/virt/kvm/api.rst\n+++ b/Documentation/virt/kvm/api.rst\n@@ -5812,6 +5812,19 @@ KVM_XEN_VCPU_ATTR_TYPE_UPCALL_VECTOR\n vector configured with HVM_PARAM_CALLBACK_IRQ. It is disabled by\n setting the vector to zero.\n \n+KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE\n+ This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates\n+ support for KVM_XEN_HVM_CONFIG_WRITE_HYPERCALL_PAGE. It triggers\n+ population of the Xen hypercall page at the guest physical address\n+ specified in ``gpa``, just as if the guest had written to the\n+ hypercall MSR. This is intended for VMMs that intercept the guest's\n+ MSR write (e.g. to track an epoch for kexec/crash recovery) and need\n+ to replay the write from host context. Direct host-initiated writes\n+ via KVM_SET_MSRS are blocked for safety; this attribute provides the\n+ correct alternative. As with a non-intercepted guest write to the\n+ hypercall MSR, it also latches the 'long mode' for the VM, which\n+ determines the layout of the shared data structures.\n+\n \n 4.129 KVM_XEN_VCPU_GET_ATTR\n ---------------------------\ndiff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h\nindex 1585ec8040666e..7732b92a4db02e 100644\n--- a/arch/x86/include/uapi/asm/kvm.h\n+++ b/arch/x86/include/uapi/asm/kvm.h\n@@ -598,6 +598,7 @@ struct kvm_x86_mce {\n #define KVM_XEN_HVM_CONFIG_RUNSTATE_UPDATE_FLAG\t(1 \u003c\u003c 6)\n #define KVM_XEN_HVM_CONFIG_PVCLOCK_TSC_UNSTABLE\t(1 \u003c\u003c 7)\n #define KVM_XEN_HVM_CONFIG_SHARED_INFO_HVA\t(1 \u003c\u003c 8)\n+#define KVM_XEN_HVM_CONFIG_WRITE_HYPERCALL_PAGE\t(1 \u003c\u003c 9)\n \n #define KVM_XEN_MSR_MIN_INDEX\t\t\t0x40000000u\n #define KVM_XEN_MSR_MAX_INDEX\t\t\t0x4fffffffu\n@@ -706,6 +707,8 @@ struct kvm_xen_vcpu_attr {\n #define KVM_XEN_VCPU_ATTR_TYPE_UPCALL_VECTOR\t0x8\n /* Available with KVM_CAP_XEN_HVM / KVM_XEN_HVM_CONFIG_SHARED_INFO_HVA */\n #define KVM_XEN_VCPU_ATTR_TYPE_VCPU_INFO_HVA\t0x9\n+/* Available with KVM_CAP_XEN_HVM / KVM_XEN_HVM_CONFIG_WRITE_HYPERCALL_PAGE */\n+#define KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE 0xa\n \n /* Secure Encrypted Virtualization command */\n enum sev_cmd_id {\ndiff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c\nindex afcac1042947a5..d7f23c0bff7456 100644\n--- a/arch/x86/kvm/x86.c\n+++ b/arch/x86/kvm/x86.c\n@@ -4869,7 +4869,8 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)\n \t\t KVM_XEN_HVM_CONFIG_EVTCHN_2LEVEL |\n \t\t KVM_XEN_HVM_CONFIG_EVTCHN_SEND |\n \t\t KVM_XEN_HVM_CONFIG_PVCLOCK_TSC_UNSTABLE |\n-\t\t KVM_XEN_HVM_CONFIG_SHARED_INFO_HVA;\n+\t\t KVM_XEN_HVM_CONFIG_SHARED_INFO_HVA |\n+\t\t KVM_XEN_HVM_CONFIG_WRITE_HYPERCALL_PAGE;\n \t\tif (sched_info_on())\n \t\t\tr |= KVM_XEN_HVM_CONFIG_RUNSTATE |\n \t\t\t KVM_XEN_HVM_CONFIG_RUNSTATE_UPDATE_FLAG;\ndiff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c\nindex 694b31c1fcc9af..50423df6e22d9d 100644\n--- a/arch/x86/kvm/xen.c\n+++ b/arch/x86/kvm/xen.c\n@@ -32,6 +32,7 @@\n static int kvm_xen_set_evtchn(struct kvm_xen_evtchn *xe, struct kvm *kvm);\n static int kvm_xen_setattr_evtchn(struct kvm *kvm, struct kvm_xen_hvm_attr *data);\n static bool kvm_xen_hcall_evtchn_send(struct kvm_vcpu *vcpu, u64 param, u64 *r);\n+static int __kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data);\n \n DEFINE_STATIC_KEY_DEFERRED_FALSE(kvm_xen_enabled, HZ);\n \n@@ -1138,6 +1139,10 @@ int kvm_xen_vcpu_set_attr(struct kvm_vcpu *vcpu, struct kvm_xen_vcpu_attr *data)\n \t\t}\n \t\tbreak;\n \n+\tcase KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE:\n+\t\tr = __kvm_xen_write_hypercall_page(vcpu, data-\u003eu.gpa);\n+\t\tbreak;\n+\n \tdefault:\n \t\tbreak;\n \t}\n@@ -1273,7 +1278,7 @@ int kvm_xen_vcpu_get_attr(struct kvm_vcpu *vcpu, struct kvm_xen_vcpu_attr *data)\n \treturn r;\n }\n \n-int kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data)\n+static int __kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data)\n {\n \tstruct kvm *kvm = vcpu-\u003ekvm;\n \tu32 page_num = data \u0026 ~PAGE_MASK;\n@@ -1281,7 +1286,6 @@ int kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data)\n \tbool lm = is_long_mode(vcpu);\n \tint r = 0;\n \n-\tmutex_lock(\u0026kvm-\u003earch.xen.xen_lock);\n \tif (kvm-\u003earch.xen.long_mode != lm) {\n \t\tkvm-\u003earch.xen.long_mode = lm;\n \n@@ -1289,11 +1293,9 @@ int kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data)\n \t\t * Re-initialize shared_info to put the wallclock in the\n \t\t * correct place.\n \t\t */\n-\t\tif (kvm-\u003earch.xen.shinfo_cache.active \u0026\u0026\n-\t\t kvm_xen_shared_info_init(kvm))\n-\t\t\tr = 1;\n+\t\tif (kvm-\u003earch.xen.shinfo_cache.active)\n+\t\t\tr = kvm_xen_shared_info_init(kvm);\n \t}\n-\tmutex_unlock(\u0026kvm-\u003earch.xen.xen_lock);\n \n \tif (r)\n \t\treturn r;\n@@ -1309,7 +1311,7 @@ int kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data)\n \t\tint i;\n \n \t\tif (page_num)\n-\t\t\treturn 1;\n+\t\t\treturn -EINVAL;\n \n \t\t/* mov imm32, %eax */\n \t\tinstructions[0] = 0xb8;\n@@ -1325,10 +1327,11 @@ int kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data)\n \n \t\tfor (i = 0; i \u003c PAGE_SIZE / sizeof(instructions); i++) {\n \t\t\t*(u32 *)\u0026instructions[1] = i;\n-\t\t\tif (kvm_vcpu_write_guest(vcpu,\n+\t\t\tr = kvm_vcpu_write_guest(vcpu,\n \t\t\t\t\t\t page_addr + (i * sizeof(instructions)),\n-\t\t\t\t\t\t instructions, sizeof(instructions)))\n-\t\t\t\treturn 1;\n+\t\t\t\t\t\t instructions, sizeof(instructions));\n+\t\t\tif (r)\n+\t\t\t\treturn r;\n \t\t}\n \t} else {\n \t\t/*\n@@ -1340,10 +1343,9 @@ int kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data)\n \t\tu8 blob_size = lm ? kvm-\u003earch.xen.hvm_config.blob_size_64\n \t\t\t\t : kvm-\u003earch.xen.hvm_config.blob_size_32;\n \t\tu8 *page;\n-\t\tint ret;\n \n \t\tif (page_num \u003e= blob_size)\n-\t\t\treturn 1;\n+\t\t\treturn -EINVAL;\n \n \t\tblob_addr += page_num * PAGE_SIZE;\n \n@@ -1351,14 +1353,27 @@ int kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data)\n \t\tif (IS_ERR(page))\n \t\t\treturn PTR_ERR(page);\n \n-\t\tret = kvm_vcpu_write_guest(vcpu, page_addr, page, PAGE_SIZE);\n+\t\tr = kvm_vcpu_write_guest(vcpu, page_addr, page, PAGE_SIZE);\n \t\tkfree(page);\n-\t\tif (ret)\n-\t\t\treturn 1;\n+\t\tif (r)\n+\t\t\treturn r;\n \t}\n \treturn 0;\n }\n \n+int kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data)\n+{\n+\tguard(mutex)(\u0026vcpu-\u003ekvm-\u003earch.xen.xen_lock);\n+\n+\t/*\n+\t * The MSR write path expects a 0/1 return; convert the errno from\n+\t * the shared helper accordingly. Callers that want the real error\n+\t * (e.g. the KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE attribute)\n+\t * invoke __kvm_xen_write_hypercall_page() directly.\n+\t */\n+\treturn __kvm_xen_write_hypercall_page(vcpu, data) ? 1 : 0;\n+}\n+\n int kvm_xen_hvm_config(struct kvm *kvm, struct kvm_xen_hvm_config *xhc)\n {\n \t/* Only some feature flags need to be *enabled* by userspace */\ndiff --git a/tools/testing/selftests/kvm/x86/xen_vmcall_test.c b/tools/testing/selftests/kvm/x86/xen_vmcall_test.c\nindex 2585087cdf5cbe..1536d510ab3019 100644\n--- a/tools/testing/selftests/kvm/x86/xen_vmcall_test.c\n+++ b/tools/testing/selftests/kvm/x86/xen_vmcall_test.c\n@@ -12,6 +12,8 @@\n #include \"processor.h\"\n #include \"hyperv.h\"\n \n+#include \u003cstring.h\u003e\n+\n #define HCALL_REGION_GPA\t0xc0000000ULL\n #define HCALL_REGION_SLOT\t10\n \n@@ -26,6 +28,10 @@\n #define HVCALL_SIGNAL_EVENT\t\t0x005d\n #define HV_STATUS_INVALID_ALIGNMENT\t4\n \n+enum {\n+\tTEST_WRITE_HYPERCALL_PAGE = 1,\n+};\n+\n static void guest_code(void)\n {\n \tunsigned long rax = INPUTVALUE;\n@@ -76,17 +82,65 @@ static void guest_code(void)\n \t\t\t \"r\"(r8));\n \tGUEST_ASSERT(rax == HV_STATUS_INVALID_ALIGNMENT);\n \n+\t/*\n+\t * Test KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE: ask userspace\n+\t * to set up MSR filtering, then write the MSR. The WRMSR will exit\n+\t * to userspace (not populate the page). Userspace verifies the page\n+\t * is empty, uses the attr to populate it, then resumes us.\n+\t */\n+\tGUEST_SYNC(TEST_WRITE_HYPERCALL_PAGE);\n+\n+\t__asm__ __volatile__(\"wrmsr\" : : \"c\" (XEN_HYPERCALL_MSR),\n+\t\t\t \"a\" (HCALL_REGION_GPA \u0026 0xffffffff),\n+\t\t\t \"d\" (HCALL_REGION_GPA \u003e\u003e 32));\n+\n+\t/* Userspace populated the page via the attr — verify it works */\n+\trax = INPUTVALUE;\n+\trdi = ARGVALUE(1);\n+\trsi = ARGVALUE(2);\n+\trdx = ARGVALUE(3);\n+\tr10 = ARGVALUE(4);\n+\tr8 = ARGVALUE(5);\n+\tr9 = ARGVALUE(6);\n+\t__asm__ __volatile__(\"call *%1\" : \"=a\"(rax) :\n+\t\t\t \"r\"(HCALL_REGION_GPA + INPUTVALUE * 32),\n+\t\t\t \"a\"(rax), \"D\"(rdi), \"S\"(rsi), \"d\"(rdx),\n+\t\t\t \"r\"(r10), \"r\"(r8), \"r\"(r9));\n+\tGUEST_ASSERT(rax == RETVALUE);\n+\n \tGUEST_DONE();\n }\n \n+static void setup_msr_filter(struct kvm_vm *vm)\n+{\n+\tuint64_t deny_bits = 0;\n+\tstruct kvm_msr_filter filter = {\n+\t\t.flags = KVM_MSR_FILTER_DEFAULT_ALLOW,\n+\t\t.ranges = {\n+\t\t\t{\n+\t\t\t\t.flags = KVM_MSR_FILTER_WRITE,\n+\t\t\t\t.nmsrs = 1,\n+\t\t\t\t.base = XEN_HYPERCALL_MSR,\n+\t\t\t\t.bitmap = (uint8_t *)\u0026deny_bits,\n+\t\t\t},\n+\t\t},\n+\t};\n+\n+\tvm_ioctl(vm, KVM_X86_SET_MSR_FILTER, \u0026filter);\n+}\n+\n int main(int argc, char *argv[])\n {\n \tunsigned int xen_caps;\n \tstruct kvm_vcpu *vcpu;\n \tstruct kvm_vm *vm;\n+\tbool msr_filter_ready = false;\n \n \txen_caps = kvm_check_cap(KVM_CAP_XEN_HVM);\n \tTEST_REQUIRE(xen_caps \u0026 KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL);\n+\tTEST_REQUIRE(xen_caps \u0026 KVM_XEN_HVM_CONFIG_WRITE_HYPERCALL_PAGE);\n+\tTEST_REQUIRE(kvm_check_cap(KVM_CAP_X86_USER_SPACE_MSR));\n+\tTEST_REQUIRE(kvm_check_cap(KVM_CAP_X86_MSR_FILTER));\n \n \tvm = vm_create_with_one_vcpu(\u0026vcpu, guest_code);\n \tvcpu_set_hv_cpuid(vcpu);\n@@ -123,6 +177,36 @@ int main(int argc, char *argv[])\n \t\t\tcontinue;\n \t\t}\n \n+\t\tif (run-\u003eexit_reason == KVM_EXIT_X86_WRMSR) {\n+\t\t\t/* MSR filter caught the Xen hypercall MSR write */\n+\t\t\tTEST_ASSERT(msr_filter_ready,\n+\t\t\t\t \"Unexpected WRMSR exit before filter setup\");\n+\t\t\tTEST_ASSERT_EQ(run-\u003emsr.index, XEN_HYPERCALL_MSR);\n+\n+\t\t\t/*\n+\t\t\t * The host_initiated check should have prevented\n+\t\t\t * KVM from populating the page. Verify it's empty.\n+\t\t\t */\n+\t\t\tuint8_t *hcall_page = addr_gpa2hva(vm, HCALL_REGION_GPA);\n+\t\t\tTEST_ASSERT_EQ(hcall_page[0], 0);\n+\n+\t\t\t/*\n+\t\t\t * Now use the attr to populate the page, as a\n+\t\t\t * VMM would after intercepting the MSR write.\n+\t\t\t */\n+\t\t\tstruct kvm_xen_vcpu_attr attr = {\n+\t\t\t\t.type = KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE,\n+\t\t\t\t.u.gpa = HCALL_REGION_GPA,\n+\t\t\t};\n+\t\t\tvcpu_ioctl(vcpu, KVM_XEN_VCPU_SET_ATTR, \u0026attr);\n+\n+\t\t\t/* Verify the page is now populated */\n+\t\t\tTEST_ASSERT_EQ(hcall_page[0], 0xb8);\n+\n+\t\t\trun-\u003emsr.error = 0;\n+\t\t\tcontinue;\n+\t\t}\n+\n \t\tTEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_IO);\n \n \t\tswitch (get_ucall(vcpu, \u0026uc)) {\n@@ -130,6 +214,18 @@ int main(int argc, char *argv[])\n \t\t\tREPORT_GUEST_ASSERT(uc);\n \t\t\t/* NOT REACHED */\n \t\tcase UCALL_SYNC:\n+\t\t\tTEST_ASSERT_EQ(uc.args[1], TEST_WRITE_HYPERCALL_PAGE);\n+\n+\t\t\t/*\n+\t\t\t * Guest is about to write the Xen MSR. Clear the\n+\t\t\t * hypercall page, install MSR filter to intercept\n+\t\t\t * the write, and enable userspace MSR exits.\n+\t\t\t */\n+\t\t\tmemset(addr_gpa2hva(vm, HCALL_REGION_GPA), 0, PAGE_SIZE);\n+\t\t\tvm_enable_cap(vm, KVM_CAP_X86_USER_SPACE_MSR,\n+\t\t\t\t KVM_MSR_EXIT_REASON_FILTER);\n+\t\t\tsetup_msr_filter(vm);\n+\t\t\tmsr_filter_ready = true;\n \t\t\tbreak;\n \t\tcase UCALL_DONE:\n \t\t\tgoto done;\n"
} |
| 2/1 | 2026/06/29 17:09 | agent | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: {
"EnableConfigs": [
"KVM",
"KVM_XEN"
],
"FocusSymbols": [
"kvm_xen_vcpu_set_attr",
"__kvm_xen_write_hypercall_page"
],
"Reasoning": "The patch adds a new KVM Xen VCPU attribute `KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE` which allows userspace to trigger the population of the Xen hypercall page. This is reachable from userspace via the `KVM_XEN_VCPU_SET_ATTR` ioctl and modifies core KVM Xen emulation logic.",
"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 a4f79f499cea58c3c182ae88f9fcc55d174be17f
Author: syz-cluster <triage@syzkaller.com>
Date: Mon Jun 29 17:09:37 2026 +0000
syz-cluster: applied patch under review
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index a5f9ee92f43e8d..3c6aee2a35bfdc 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -5812,6 +5812,19 @@ KVM_XEN_VCPU_ATTR_TYPE_UPCALL_VECTOR
vector configured with HVM_PARAM_CALLBACK_IRQ. It is disabled by
setting the vector to zero.
+KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE
+ This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates
+ support for KVM_XEN_HVM_CONFIG_WRITE_HYPERCALL_PAGE. It triggers
+ population of the Xen hypercall page at the guest physical address
+ specified in ``gpa``, just as if the guest had written to the
+ hypercall MSR. This is intended for VMMs that intercept the guest's
+ MSR write (e.g. to track an epoch for kexec/crash recovery) and need
+ to replay the write from host context. Direct host-initiated writes
+ via KVM_SET_MSRS are blocked for safety; this attribute provides the
+ correct alternative. As with a non-intercepted guest write to the
+ hypercall MSR, it also latches the 'long mode' for the VM, which
+ determines the layout of the shared data structures.
+
4.129 KVM_XEN_VCPU_GET_ATTR
---------------------------
diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
index 1585ec8040666e..7732b92a4db02e 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -598,6 +598,7 @@ struct kvm_x86_mce {
#define KVM_XEN_HVM_CONFIG_RUNSTATE_UPDATE_FLAG (1 << 6)
#define KVM_XEN_HVM_CONFIG_PVCLOCK_TSC_UNSTABLE (1 << 7)
#define KVM_XEN_HVM_CONFIG_SHARED_INFO_HVA (1 << 8)
+#define KVM_XEN_HVM_CONFIG_WRITE_HYPERCALL_PAGE (1 << 9)
#define KVM_XEN_MSR_MIN_INDEX 0x40000000u
#define KVM_XEN_MSR_MAX_INDEX 0x4fffffffu
@@ -706,6 +707,8 @@ struct kvm_xen_vcpu_attr {
#define KVM_XEN_VCPU_ATTR_TYPE_UPCALL_VECTOR 0x8
/* Available with KVM_CAP_XEN_HVM / KVM_XEN_HVM_CONFIG_SHARED_INFO_HVA */
#define KVM_XEN_VCPU_ATTR_TYPE_VCPU_INFO_HVA 0x9
+/* Available with KVM_CAP_XEN_HVM / KVM_XEN_HVM_CONFIG_WRITE_HYPERCALL_PAGE */
+#define KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE 0xa
/* Secure Encrypted Virtualization command */
enum sev_cmd_id {
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index afcac1042947a5..d7f23c0bff7456 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4869,7 +4869,8 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
KVM_XEN_HVM_CONFIG_EVTCHN_2LEVEL |
KVM_XEN_HVM_CONFIG_EVTCHN_SEND |
KVM_XEN_HVM_CONFIG_PVCLOCK_TSC_UNSTABLE |
- KVM_XEN_HVM_CONFIG_SHARED_INFO_HVA;
+ KVM_XEN_HVM_CONFIG_SHARED_INFO_HVA |
+ KVM_XEN_HVM_CONFIG_WRITE_HYPERCALL_PAGE;
if (sched_info_on())
r |= KVM_XEN_HVM_CONFIG_RUNSTATE |
KVM_XEN_HVM_CONFIG_RUNSTATE_UPDATE_FLAG;
diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
index 694b31c1fcc9af..50423df6e22d9d 100644
--- a/arch/x86/kvm/xen.c
+++ b/arch/x86/kvm/xen.c
@@ -32,6 +32,7 @@
static int kvm_xen_set_evtchn(struct kvm_xen_evtchn *xe, struct kvm *kvm);
static int kvm_xen_setattr_evtchn(struct kvm *kvm, struct kvm_xen_hvm_attr *data);
static bool kvm_xen_hcall_evtchn_send(struct kvm_vcpu *vcpu, u64 param, u64 *r);
+static int __kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data);
DEFINE_STATIC_KEY_DEFERRED_FALSE(kvm_xen_enabled, HZ);
@@ -1138,6 +1139,10 @@ int kvm_xen_vcpu_set_attr(struct kvm_vcpu *vcpu, struct kvm_xen_vcpu_attr *data)
}
break;
+ case KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE:
+ r = __kvm_xen_write_hypercall_page(vcpu, data->u.gpa);
+ break;
+
default:
break;
}
@@ -1273,7 +1278,7 @@ int kvm_xen_vcpu_get_attr(struct kvm_vcpu *vcpu, struct kvm_xen_vcpu_attr *data)
return r;
}
-int kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data)
+static int __kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data)
{
struct kvm *kvm = vcpu->kvm;
u32 page_num = data & ~PAGE_MASK;
@@ -1281,7 +1286,6 @@ int kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data)
bool lm = is_long_mode(vcpu);
int r = 0;
- mutex_lock(&kvm->arch.xen.xen_lock);
if (kvm->arch.xen.long_mode != lm) {
kvm->arch.xen.long_mode = lm;
@@ -1289,11 +1293,9 @@ int kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data)
* Re-initialize shared_info to put the wallclock in the
* correct place.
*/
- if (kvm->arch.xen.shinfo_cache.active &&
- kvm_xen_shared_info_init(kvm))
- r = 1;
+ if (kvm->arch.xen.shinfo_cache.active)
+ r = kvm_xen_shared_info_init(kvm);
}
- mutex_unlock(&kvm->arch.xen.xen_lock);
if (r)
return r;
@@ -1309,7 +1311,7 @@ int kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data)
int i;
if (page_num)
- return 1;
+ return -EINVAL;
/* mov imm32, %eax */
instructions[0] = 0xb8;
@@ -1325,10 +1327,11 @@ int kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data)
for (i = 0; i < PAGE_SIZE / sizeof(instructions); i++) {
*(u32 *)&instructions[1] = i;
- if (kvm_vcpu_write_guest(vcpu,
+ r = kvm_vcpu_write_guest(vcpu,
page_addr + (i * sizeof(instructions)),
- instructions, sizeof(instructions)))
- return 1;
+ instructions, sizeof(instructions));
+ if (r)
+ return r;
}
} else {
/*
@@ -1340,10 +1343,9 @@ int kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data)
u8 blob_size = lm ? kvm->arch.xen.hvm_config.blob_size_64
: kvm->arch.xen.hvm_config.blob_size_32;
u8 *page;
- int ret;
if (page_num >= blob_size)
- return 1;
+ return -EINVAL;
blob_addr += page_num * PAGE_SIZE;
@@ -1351,14 +1353,27 @@ int kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data)
if (IS_ERR(page))
return PTR_ERR(page);
- ret = kvm_vcpu_write_guest(vcpu, page_addr, page, PAGE_SIZE);
+ r = kvm_vcpu_write_guest(vcpu, page_addr, page, PAGE_SIZE);
kfree(page);
- if (ret)
- return 1;
+ if (r)
+ return r;
}
return 0;
}
+int kvm_xen_write_hypercall_page(struct kvm_vcpu *vcpu, u64 data)
+{
+ guard(mutex)(&vcpu->kvm->arch.xen.xen_lock);
+
+ /*
+ * The MSR write path expects a 0/1 return; convert the errno from
+ * the shared helper accordingly. Callers that want the real error
+ * (e.g. the KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE attribute)
+ * invoke __kvm_xen_write_hypercall_page() directly.
+ */
+ return __kvm_xen_write_hypercall_page(vcpu, data) ? 1 : 0;
+}
+
int kvm_xen_hvm_config(struct kvm *kvm, struct kvm_xen_hvm_config *xhc)
{
/* Only some feature flags need to be *enabled* by userspace */
diff --git a/tools/testing/selftests/kvm/x86/xen_vmcall_test.c b/tools/testing/selftests/kvm/x86/xen_vmcall_test.c
index 2585087cdf5cbe..1536d510ab3019 100644
--- a/tools/testing/selftests/kvm/x86/xen_vmcall_test.c
+++ b/tools/testing/selftests/kvm/x86/xen_vmcall_test.c
@@ -12,6 +12,8 @@
#include "processor.h"
#include "hyperv.h"
+#include <string.h>
+
#define HCALL_REGION_GPA 0xc0000000ULL
#define HCALL_REGION_SLOT 10
@@ -26,6 +28,10 @@
#define HVCALL_SIGNAL_EVENT 0x005d
#define HV_STATUS_INVALID_ALIGNMENT 4
+enum {
+ TEST_WRITE_HYPERCALL_PAGE = 1,
+};
+
static void guest_code(void)
{
unsigned long rax = INPUTVALUE;
@@ -76,17 +82,65 @@ static void guest_code(void)
"r"(r8));
GUEST_ASSERT(rax == HV_STATUS_INVALID_ALIGNMENT);
+ /*
+ * Test KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE: ask userspace
+ * to set up MSR filtering, then write the MSR. The WRMSR will exit
+ * to userspace (not populate the page). Userspace verifies the page
+ * is empty, uses the attr to populate it, then resumes us.
+ */
+ GUEST_SYNC(TEST_WRITE_HYPERCALL_PAGE);
+
+ __asm__ __volatile__("wrmsr" : : "c" (XEN_HYPERCALL_MSR),
+ "a" (HCALL_REGION_GPA & 0xffffffff),
+ "d" (HCALL_REGION_GPA >> 32));
+
+ /* Userspace populated the page via the attr — verify it works */
+ rax = INPUTVALUE;
+ rdi = ARGVALUE(1);
+ rsi = ARGVALUE(2);
+ rdx = ARGVALUE(3);
+ r10 = ARGVALUE(4);
+ r8 = ARGVALUE(5);
+ r9 = ARGVALUE(6);
+ __asm__ __volatile__("call *%1" : "=a"(rax) :
+ "r"(HCALL_REGION_GPA + INPUTVALUE * 32),
+ "a"(rax), "D"(rdi), "S"(rsi), "d"(rdx),
+ "r"(r10), "r"(r8), "r"(r9));
+ GUEST_ASSERT(rax == RETVALUE);
+
GUEST_DONE();
}
+static void setup_msr_filter(struct kvm_vm *vm)
+{
+ uint64_t deny_bits = 0;
+ struct kvm_msr_filter filter = {
+ .flags = KVM_MSR_FILTER_DEFAULT_ALLOW,
+ .ranges = {
+ {
+ .flags = KVM_MSR_FILTER_WRITE,
+ .nmsrs = 1,
+ .base = XEN_HYPERCALL_MSR,
+ .bitmap = (uint8_t *)&deny_bits,
+ },
+ },
+ };
+
+ vm_ioctl(vm, KVM_X86_SET_MSR_FILTER, &filter);
+}
+
int main(int argc, char *argv[])
{
unsigned int xen_caps;
struct kvm_vcpu *vcpu;
struct kvm_vm *vm;
+ bool msr_filter_ready = false;
xen_caps = kvm_check_cap(KVM_CAP_XEN_HVM);
TEST_REQUIRE(xen_caps & KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL);
+ TEST_REQUIRE(xen_caps & KVM_XEN_HVM_CONFIG_WRITE_HYPERCALL_PAGE);
+ TEST_REQUIRE(kvm_check_cap(KVM_CAP_X86_USER_SPACE_MSR));
+ TEST_REQUIRE(kvm_check_cap(KVM_CAP_X86_MSR_FILTER));
vm = vm_create_with_one_vcpu(&vcpu, guest_code);
vcpu_set_hv_cpuid(vcpu);
@@ -123,6 +177,36 @@ int main(int argc, char *argv[])
continue;
}
+ if (run->exit_reason == KVM_EXIT_X86_WRMSR) {
+ /* MSR filter caught the Xen hypercall MSR write */
+ TEST_ASSERT(msr_filter_ready,
+ "Unexpected WRMSR exit before filter setup");
+ TEST_ASSERT_EQ(run->msr.index, XEN_HYPERCALL_MSR);
+
+ /*
+ * The host_initiated check should have prevented
+ * KVM from populating the page. Verify it's empty.
+ */
+ uint8_t *hcall_page = addr_gpa2hva(vm, HCALL_REGION_GPA);
+ TEST_ASSERT_EQ(hcall_page[0], 0);
+
+ /*
+ * Now use the attr to populate the page, as a
+ * VMM would after intercepting the MSR write.
+ */
+ struct kvm_xen_vcpu_attr attr = {
+ .type = KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE,
+ .u.gpa = HCALL_REGION_GPA,
+ };
+ vcpu_ioctl(vcpu, KVM_XEN_VCPU_SET_ATTR, &attr);
+
+ /* Verify the page is now populated */
+ TEST_ASSERT_EQ(hcall_page[0], 0xb8);
+
+ run->msr.error = 0;
+ continue;
+ }
+
TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_IO);
switch (get_ucall(vcpu, &uc)) {
@@ -130,6 +214,18 @@ int main(int argc, char *argv[])
REPORT_GUEST_ASSERT(uc);
/* NOT REACHED */
case UCALL_SYNC:
+ TEST_ASSERT_EQ(uc.args[1], TEST_WRITE_HYPERCALL_PAGE);
+
+ /*
+ * Guest is about to write the Xen MSR. Clear the
+ * hypercall page, install MSR filter to intercept
+ * the write, and enable userspace MSR exits.
+ */
+ memset(addr_gpa2hva(vm, HCALL_REGION_GPA), 0, PAGE_SIZE);
+ vm_enable_cap(vm, KVM_CAP_X86_USER_SPACE_MSR,
+ KVM_MSR_EXIT_REASON_FILTER);
+ setup_msr_filter(vm);
+ msr_filter_ready = true;
break;
case UCALL_DONE:
goto done;
|
| 3/2 | 2026/06/29 17:09 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 6525 output: 36 thoughts: 500 Thoughts: **Analyzing the KVM Xen VCPU Hypercall Page Patch** Okay, so I've got this patch here that introduces a new KVM Xen VCPU attribute, `KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE`. The gist is, it allows userspace to trigger the Xen hypercall page population at a specified guest physical address. It's basically a safer way to do it, bypassing the direct MSR write, which is blocked for security reasons when the host tries to write to the hypercall page. Smart. Let's dissect this thing. First, documentation in `Documentation/virt/kvm/api.rst` - gotta make sure that's up to snuff. Then, the usual suspects: `arch/x86/include/uapi/asm/kvm.h` adding the new definitions `KVM_XEN_HVM_CONFIG_WRITE_HYPERCALL_PAGE` and `KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE`. `arch/x86/kvm/x86.c` includes the `KVM_XEN_HVM_CONFIG_WRITE_HYPERCALL_PAGE` in `kvm_vm_ioctl_check_extension`. Standard stuff so far. Now, here's where the meat is, `arch/x86/kvm/xen.c`. This is where the magic happens, handling `KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE` in `kvm_xen_vcpu_set_attr`. It's calling `__kvm_xen_write_hypercall_page(vcpu, data->u.gpa)`. Ah, and I see they refactored the existing `kvm_xen_write_hypercall_page` into this internal function `__kvm_xen_write_hypercall_page` to return proper error codes like `-EINVAL`, instead of returning `1` on error. Then the original `kvm_xen_write_hypercall_page` wraps that to stay backward compatible. Good move, cleaner error handling. And finally, we've got a selftest, `tools/testing/selftests/kvm/x86/xen_vmcall_test.c`, so it's tested. Excellent! So, this is a functional change to the KVM Xen emulation, reachable from userspace via the `KVM_XEN_VCPU_SET_ATTR` ioctl. Right, given that it's userspace-facing, and deals with hypercalls, we absolutely need to fuzz this! I need to identify the relevant Kconfigs. Let's check `arch/x86/kvm/Kconfig` for `KVM` and `KVM_XEN`... got it. |
| 4/2 | 2026/06/29 17:09 | tool | grepper |
0mArgs:{
"Expression": "KVM_XEN",
"PathPrefix": "arch/x86/kvm/Kconfig"
}Results: {
"Output": "arch/x86/kvm/Kconfig=193=config KVM_HYPERV\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"
} |
| 5/2 | 2026/06/29 17:09 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 7788 output: 34 thoughts: 142 Thoughts: **Analyzing KVM/Xen Configuration for Potential Performance Bottlenecks** Okay, so I'm looking at these configurations, `KVM` and `KVM_XEN`, and I'm trying to pinpoint where the focus lies. Time to dig into the symbols. Let's see... I've got `kvm_xen_vcpu_set_attr`, `__kvm_xen_write_hypercall_page`, and `kvm_xen_write_hypercall_page`. My initial thought is to figure out if `kvm_xen_vcpu_set_attr` is even worth a deeper look in terms of being a hot path. Ah, ioctl handler, not a primary concern for performance right now. Now, that leaves `__kvm_xen_write_hypercall_page`. That's the newer function, so it makes sense to focus there. Just going to quickly re-validate those config options and make sure I haven't missed anything obvious. |
| 6/2 | 2026/06/29 17:10 | tool | grepper |
0mArgs:{
"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"
} |
| 7/2 | 2026/06/29 17:10 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 9394 output: 40 thoughts: 75 Thoughts: Okay, here's my take on those thoughts, framed as my own mental processing: **Analyzing KVM-Xen Configuration and Key Function Symbols** Alright, so we're talking about `KVM` and `KVM_XEN` configurations here. That's a good starting point. My initial thought process is immediately drawn to the key configuration identifiers, and what they mean from an architectural standpoint. Now, I'm zeroing in on a couple of function symbols. Specifically, I see `kvm_xen_vcpu_set_attr` and `__kvm_xen_write_hypercall_page`. These *feel* significant, and I'm instantly thinking about the core mechanisms. `kvm_xen_vcpu_set_attr` immediately stands out. It's screaming "virtual CPU attribute manipulation" and the Xen integration is key. That makes me wonder about the specific context and where it operates with the hypervisor. I need to confirm if `kvm_xen_vcpu_set_attr` is a solid focus symbol. I suspect it's central to how KVM interacts with Xen to manage virtual CPUs. Let's see if this function is actually the right place to begin diving deeper. I want to understand how it maps to Xen's structures and how it handles the interaction between the two virtual machine monitors. I need to understand this better. |
| 8/2 | 2026/06/29 17:10 | tool | grepper |
0mArgs:{
"Expression": "kvm_xen_vcpu_set_attr",
"PathPrefix": "arch/x86/kvm/"
}Results: {
"Output": "arch/x86/kvm/x86.c=6190=long kvm_arch_vcpu_ioctl(struct file *filp,\n--\narch/x86/kvm/x86.c-6612-\t\t\tgoto out;\narch/x86/kvm/x86.c:6613:\t\tr = kvm_xen_vcpu_set_attr(vcpu, \u0026xva);\narch/x86/kvm/x86.c-6614-\t\tbreak;\n--\narch/x86/kvm/xen.c=852=int kvm_xen_hvm_get_attr(struct kvm *kvm, struct kvm_xen_hvm_attr *data)\n--\narch/x86/kvm/xen.c-906-\narch/x86/kvm/xen.c:907:int kvm_xen_vcpu_set_attr(struct kvm_vcpu *vcpu, struct kvm_xen_vcpu_attr *data)\narch/x86/kvm/xen.c-908-{\n--\narch/x86/kvm/xen.h=22=void kvm_xen_inject_vcpu_vector(struct kvm_vcpu *vcpu);\narch/x86/kvm/xen.h:23:int kvm_xen_vcpu_set_attr(struct kvm_vcpu *vcpu, struct kvm_xen_vcpu_attr *data);\narch/x86/kvm/xen.h-24-int kvm_xen_vcpu_get_attr(struct kvm_vcpu *vcpu, struct kvm_xen_vcpu_attr *data);\n"
} |
| 9/2 | 2026/06/29 17:10 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 10241 output: 152 thoughts: 234 Thoughts: **Analyzing KVM-Xen Hypercall Page Population** Okay, so `kvm_xen_vcpu_set_attr` is definitely an important piece of this puzzle; it's the ioctl handler for `KVM_XEN_VCPU_SET_ATTR`, making it a key focus point. And, of course, `__kvm_xen_write_hypercall_page` looks equally critical. I need to keep those at the forefront. Let's see, are there any other relevant kernel configurations that might be important here? Ah, yes, `KVM_XEN` depends on `KVM`. Got it. In short, this is worth fuzzing. The addition of `KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE` and its associated functionality - specifically the ability for userspace to trigger the population of the Xen hypercall page - is interesting. It's directly reachable from userspace through the `KVM_XEN_VCPU_SET_ATTR` ioctl and fundamentally alters the core KVM Xen emulation. My focus should be on the areas around those two symbols: `kvm_xen_vcpu_set_attr` and `__kvm_xen_write_hypercall_page`. I will want to ensure the following configurations are enabled: `KVM` and `KVM_XEN`. |
| 10/2 | 2026/06/29 17:10 | tool | set-results |
0mArgs:{
"EnableConfigs": [
"KVM",
"KVM_XEN"
],
"FocusSymbols": [
"kvm_xen_vcpu_set_attr",
"__kvm_xen_write_hypercall_page"
],
"Reasoning": "The patch adds a new KVM Xen VCPU attribute `KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE` which allows userspace to trigger the population of the Xen hypercall page. This is reachable from userspace via the `KVM_XEN_VCPU_SET_ATTR` ioctl and modifies core KVM Xen emulation logic.",
"WorthFuzzing": true
}Results: {
"EnableConfigs": [
"KVM",
"KVM_XEN"
],
"FocusSymbols": [
"kvm_xen_vcpu_set_attr",
"__kvm_xen_write_hypercall_page"
],
"Reasoning": "The patch adds a new KVM Xen VCPU attribute `KVM_XEN_VCPU_ATTR_TYPE_WRITE_HYPERCALL_PAGE` which allows userspace to trigger the population of the Xen hypercall page. This is reachable from userspace via the `KVM_XEN_VCPU_SET_ATTR` ioctl and modifies core KVM Xen emulation logic.",
"WorthFuzzing": true
} |
| Total Calls | Total Tokens | Avg Tokens | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|
| Total Calls | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|