AI Trajectory

null

{
  "EnableConfigs": [
    "KVM",
    "VIRTUALIZATION"
  ],
  "FocusSymbols": [
    "vgic_its_destroy",
    "vgic_its_set_attr",
    "vgic_mmio_write_its_baser"
  ],
  "KMSANReasoning": "The patch optimizes the teardown of ITS collections by bulk-clearing the collection pointers for all ITEs before freeing the collections, reducing the time complexity from O(Collections * ITEs) to O(Collections + ITEs) to prevent guest-triggered host RCU stalls. The changes only involve pointer assignments (`ite-\u003ecollection = NULL`) and memory deallocation (`kfree`). There are no new memory allocations, no data copied to user space, and no conditional logic depending on potentially uninitialized memory. Any bugs introduced by this change (e.g., use-after-free, NULL pointer dereference) would be reliably detected by KASAN. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false,
  "Reasoning": "The patch optimizes the teardown of KVM VGIC ITS collections by changing the complexity from O(Collections * ITEs) to O(Collections + ITEs) to prevent host RCU stalls. This is a functional change in the ARM64 KVM architecture code that is reachable during guest VM teardown or ITS reset, making it worth fuzzing.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 2d8ee5452bbbc7fa39f9001c9b1781d8007fe659\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Tue Aug 18 23:17:41 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c\nindex 36ab3e4929154..a8e819fe97898 100644\n--- a/arch/arm64/kvm/vgic/vgic-its.c\n+++ b/arch/arm64/kvm/vgic/vgic-its.c\n@@ -1133,9 +1133,21 @@ static void vgic_its_free_device_list(struct kvm *kvm, struct vgic_its *its)\n static void vgic_its_free_collection_list(struct kvm *kvm, struct vgic_its *its)\n {\n \tstruct its_collection *cur, *temp;\n+\tstruct its_device *device;\n+\tstruct its_ite *ite;\n \n-\tlist_for_each_entry_safe(cur, temp, \u0026its-\u003ecollection_list, coll_list)\n-\t\tvgic_its_free_collection(its, cur-\u003ecollection_id);\n+\t/*\n+\t * Bulk-clear the collection pointers for all ITEs.\n+\t * This transforms the teardown complexity from O(Collections * ITEs)\n+\t * to O(Collections + ITEs), avoiding guest-triggered host RCU stalls.\n+\t */\n+\tfor_each_lpi_its(device, ite, its)\n+\t\tite-\u003ecollection = NULL;\n+\n+\tlist_for_each_entry_safe(cur, temp, \u0026its-\u003ecollection_list, coll_list) {\n+\t\tlist_del(\u0026cur-\u003ecoll_list);\n+\t\tkfree(cur);\n+\t}\n }\n \n /* Must be called with its_lock mutex held */\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "KVM",
    "VIRTUALIZATION"
  ],
  "FocusSymbols": [
    "vgic_its_destroy",
    "vgic_its_set_attr",
    "vgic_mmio_write_its_baser"
  ],
  "Reasoning": "The patch optimizes the teardown of KVM VGIC ITS collections by changing the complexity from O(Collections * ITEs) to O(Collections + ITEs) to prevent host RCU stalls. This is a functional change in the ARM64 KVM architecture code that is reachable during guest VM teardown or ITS reset, making it worth fuzzing.",
  "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).
- Code in vendor-specific PCIe switch, SmartNIC, or GPU drivers (e.g., mlxsw, pds_core, qed,
  ionic, amdgpu) that require physical PCIe hardware cards not emulated in standard QEMU.
- Driver .remove, .shutdown, or pci_unregister_driver teardown callbacks (e.g., igb_remove)
  that are executed only during PCI hot-unplug or sysfs driver unbind operations.

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.
   Prefer non-static, non-inlined API entrypoint functions over internal static helper functions
   (which are inlined by the compiler and do not have distinct symbol addresses).
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.
   Also check "depends on" lines in Kconfig to include any non-standard parent subsystem configs
   needed for Kbuild to compile the code statically into vmlinux. 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 2d8ee5452bbbc7fa39f9001c9b1781d8007fe659
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Aug 18 23:17:41 2026 +0000

    syz-cluster: applied patch under review

diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
index 36ab3e4929154..a8e819fe97898 100644
--- a/arch/arm64/kvm/vgic/vgic-its.c
+++ b/arch/arm64/kvm/vgic/vgic-its.c
@@ -1133,9 +1133,21 @@ static void vgic_its_free_device_list(struct kvm *kvm, struct vgic_its *its)
 static void vgic_its_free_collection_list(struct kvm *kvm, struct vgic_its *its)
 {
 	struct its_collection *cur, *temp;
+	struct its_device *device;
+	struct its_ite *ite;
 
-	list_for_each_entry_safe(cur, temp, &its->collection_list, coll_list)
-		vgic_its_free_collection(its, cur->collection_id);
+	/*
+	 * Bulk-clear the collection pointers for all ITEs.
+	 * This transforms the teardown complexity from O(Collections * ITEs)
+	 * to O(Collections + ITEs), avoiding guest-triggered host RCU stalls.
+	 */
+	for_each_lpi_its(device, ite, its)
+		ite->collection = NULL;
+
+	list_for_each_entry_safe(cur, temp, &its->collection_list, coll_list) {
+		list_del(&cur->coll_list);
+		kfree(cur);
+	}
 }
 
 /* Must be called with its_lock mutex held */

gemini-3.1-pro-preview

null

null

							input: 2227
							output: 24
							thoughts: 187
						

**Analyzing a KVM/ARM64 Patch for ITS Cleanup**

Okay, so I'm looking at a patch that tweaks the `vgic_its_free_collection_list` function in `arch/arm64/kvm/vgic/vgic-its.c`. It seems they've changed the way collections are freed, specifically within the ITS code. Instead of the previous approach, which essentially looped through all collections and then potentially all ITEs per collection, the new method iterates through ITEs and nulls out the `collection` pointer for each, and *then* frees the collections. Smart.

The stated goal is clearly optimization; they're aiming to avoid an O(Collections * ITEs) complexity issue, which I recognize could lead to some significant RCU stalls, especially in a heavily loaded system. We're talking about KVM code, targetted to ARM64 architecture, so the stakes are pretty high if there's a performance bottleneck.

My immediate thought is, is this optimization even *reachable* in a typical use case? Is it worth the effort to thoroughly fuzz this modified function to ensure correctness? The context here is ITS teardown or destruction, and a quick search for calls to `vgic_its_free_collection_list` is definitely in order. Gotta figure out the likely scenarios where this code is executed to assess the risk/reward of diving deeper.

{
  "Expression": "vgic_its_free_collection_list"
}

{
  "Output": "arch/arm64/kvm/vgic/vgic-its.c=1124=static void vgic_its_free_device_list(struct kvm *kvm, struct vgic_its *its)\n--\narch/arm64/kvm/vgic/vgic-its.c-1132-/* its lock must be held */\narch/arm64/kvm/vgic/vgic-its.c:1133:static void vgic_its_free_collection_list(struct kvm *kvm, struct vgic_its *its)\narch/arm64/kvm/vgic/vgic-its.c-1134-{\n--\narch/arm64/kvm/vgic/vgic-its.c=1667=static void vgic_mmio_write_its_baser(struct kvm *kvm,\n--\narch/arm64/kvm/vgic/vgic-its.c-1713-\t\tcase GITS_BASER_TYPE_COLLECTION:\narch/arm64/kvm/vgic/vgic-its.c:1714:\t\t\tvgic_its_free_collection_list(kvm, its);\narch/arm64/kvm/vgic/vgic-its.c-1715-\t\t\tbreak;\n--\narch/arm64/kvm/vgic/vgic-its.c=1924=static void vgic_its_destroy(struct kvm_device *kvm_dev)\n--\narch/arm64/kvm/vgic/vgic-its.c-1933-\tvgic_its_free_device_list(kvm, its);\narch/arm64/kvm/vgic/vgic-its.c:1934:\tvgic_its_free_collection_list(kvm, its);\narch/arm64/kvm/vgic/vgic-its.c-1935-\tvgic_its_invalidate_cache(its);\n--\narch/arm64/kvm/vgic/vgic-its.c=2569=static int vgic_its_restore_collection_table(struct vgic_its *its)\n--\narch/arm64/kvm/vgic/vgic-its.c-2596-\tif (ret \u003c 0)\narch/arm64/kvm/vgic/vgic-its.c:2597:\t\tvgic_its_free_collection_list(its-\u003edev-\u003ekvm, its);\narch/arm64/kvm/vgic/vgic-its.c-2598-\n--\narch/arm64/kvm/vgic/vgic-its.c=2622=static int vgic_its_restore_tables_v0(struct vgic_its *its)\n--\narch/arm64/kvm/vgic/vgic-its.c-2631-\tif (ret)\narch/arm64/kvm/vgic/vgic-its.c:2632:\t\tvgic_its_free_collection_list(its-\u003edev-\u003ekvm, its);\narch/arm64/kvm/vgic/vgic-its.c-2633-\treturn ret;\n--\narch/arm64/kvm/vgic/vgic-its.c=2651=static void vgic_its_reset(struct kvm *kvm, struct vgic_its *its)\n--\narch/arm64/kvm/vgic/vgic-its.c-2660-\tvgic_its_free_device_list(kvm, its);\narch/arm64/kvm/vgic/vgic-its.c:2661:\tvgic_its_free_collection_list(kvm, its);\narch/arm64/kvm/vgic/vgic-its.c-2662-}\n"
}

gemini-3.1-pro-preview

null

null

							input: 3714
							output: 34
							thoughts: 129
						

**Fuzzing Target Identification**

Okay, so the `vgic_its_free_collection_list` function looks like a prime target for fuzzing. I can see it's called from a few key areas within the KVM VGIC ITS implementation. Specifically, `vgic_mmio_write_its_baser`, `vgic_its_destroy`, `vgic_its_restore_collection_table`, `vgic_its_restore_tables_v0`, and `vgic_its_reset` are all making use of it. Given its integration with those critical components, it's highly likely to be reachable during normal operation, and therefore a good candidate. The fact that we're dealing with an ARM64 architecture is also an important piece of the puzzle. Now, let me quickly double-check the Kconfig options for KVM and VGIC just to be absolutely sure I understand the relevant build configurations and dependencies before I dive deeper. This seems promising.

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

{
  "Output": "arch/arm64/kvm/Kconfig=18=if VIRTUALIZATION\narch/arm64/kvm/Kconfig-19-\narch/arm64/kvm/Kconfig:20:menuconfig KVM\narch/arm64/kvm/Kconfig-21-\tbool \"Kernel-based Virtual Machine (KVM) support\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 4185
							output: 32
							thoughts: 15
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Investigating VGIC ITS Configurations**

Okay, so I'm thinking, before I go any further, I need to verify something specific. I'm focusing on the VGIC (Virtual Generic Interrupt Controller) and its interaction with the ITS (Interrupt Translation Service). Given my understanding of the system architecture, I want to make *absolutely* sure there aren't any custom configurations or nuances related to the ITS specifically for this VGIC implementation. I know the base specifications, but past experience has taught me to always double-check for vendor-specific additions or modifications that might not be immediately obvious in the standard documentation. It's a key first step to avoid potentially wasting time chasing down issues that are simply due to a previously-known, but perhaps overlooked, configuration setting. Better to rule that out now.

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

{
  "Output": "arch/arm64/kvm/Kconfig=18=if VIRTUALIZATION\narch/arm64/kvm/Kconfig-19-\narch/arm64/kvm/Kconfig:20:menuconfig KVM\narch/arm64/kvm/Kconfig-21-\tbool \"Kernel-based Virtual Machine (KVM) support\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 4515
							output: 40
							thoughts: 31
						

Okay, let's dive into this. Here's how I'd approach that file...

**Analyzing `arch/arm64/kvm/vgic/vgic-its.c` for Conditional Compilation**

Alright, time to get my hands dirty. I'm going to jump into `arch/arm64/kvm/vgic/vgic-its.c`. The first thing I'm doing is a mental scan for any preprocessor directives – specifically, `#ifdef`, `#ifndef`, `#if`, etc. – scattered throughout the file. My goal here is to understand if this code has significant conditional compilation built into it. The ITS (Interrupt Translation Service) code is often a target for different configurations of hardware, and the `#ifdef`s are my bread and butter for spotting those differences. It is an indication of whether this code path is included in all builds or if there are different implementations based on the target system. I need to get a handle on the build's flexibility here.

{
  "Expression": "#ifdef",
  "PathPrefix": "arch/arm64/kvm/vgic/vgic-its.c"
}

{
  "Output": "arch/arm64/kvm/vgic/vgic-its.c=1867=static int vgic_its_create(struct kvm_device *dev, u32 type)\n--\narch/arm64/kvm/vgic/vgic-its.c-1893-\t/* Yep, even more trickery for lock ordering... */\narch/arm64/kvm/vgic/vgic-its.c:1894:#ifdef CONFIG_LOCKDEP\narch/arm64/kvm/vgic/vgic-its.c-1895-\tmutex_lock(\u0026its-\u003ecmd_lock);\n"
}

gemini-3.1-pro-preview

null

null

							input: 4963
							output: 34
							thoughts: 48
						

**KVM on ARM64: A Quick Look at the Build Process**

Okay, so KVM is automatically built when enabled on ARM64, that much I know. Now, I need to see exactly *how* a specific part of it, `vgic-its.o`, is brought into being. My instinct is to dive into the core of the build process, and, knowing my way around this kernel structure, that means cracking open `arch/arm64/kvm/Makefile`. That's where the magic, or at least the make rules, happens. Let's see what secrets this Makefile holds... I expect I'll find my answer there.

{
  "Expression": "vgic-its",
  "PathPrefix": "arch/arm64/kvm/Makefile"
}

{
  "Output": "arch/arm64/kvm/Makefile=16=kvm-y += arm.o mmu.o mmio.o psci.o hypercalls.o pvtime.o \\\n--\narch/arm64/kvm/Makefile-25-\t vgic/vgic-mmio-v3.o vgic/vgic-kvm-device.o \\\narch/arm64/kvm/Makefile:26:\t vgic/vgic-its.o vgic/vgic-debug.o vgic/vgic-v3-nested.o \\\narch/arm64/kvm/Makefile-27-\t vgic/vgic-v5.o\n"
}

gemini-3.1-pro-preview

null

null

							input: 5360
							output: 49
							thoughts: 464
						

**Analyzing the vgic_its_free_collection_list Patch**

Okay, so this patch is tied to the `kvm-y` build, and by extension, `CONFIG_KVM`. Right, that's the setup. It's touching `vgic_its_free_collection_list` in `vgic-its.c`, which immediately flags this as an optimization and/or bug fix designed to mitigate RCU stalls. The complexity change, from O(Collections * ITEs) down to O(Collections + ITEs), is the key indicator of a performance improvement, or a critical change to the memory model. This is definitely a functional change, altering the execution flow related to how collections are freed and ITEs are updated. This sounds like prime fuzzing material.

My focus is the `vgic_its_free_collection_list` function. It's static, so I need to find the non-static callers to understand where it's being used. Let's see... the callers are:

*   `vgic_mmio_write_its_baser` which goes through `vgic_mmio_write` -> `kvm_io_bus_write`.
*   `vgic_its_destroy` which goes through `kvm_destroy_devices` -> `kvm_destroy_vm`.
*   `vgic_its_restore_collection_table` which goes through a chain of static functions (`vgic_its_restore_tables_v0`, `vgic_its_restore_tables`, `vgic_its_set_attr`) and then finally `kvm_device_ioctl_attr`.
*   `vgic_its_reset` which also calls through that static chain to `kvm_device_ioctl_attr`.

Alright, I'll pay closer attention to `vgic_its_destroy` and `vgic_its_set_attr`. Ah, they're both callbacks within `kvm_arm_vgic_its_ops`, which is likely a key struct for the ITS device. I need to take a look at that struct definition next. This will define the lifecycle and operations of the ITS, right?

{
  "Expression": "kvm_arm_vgic_its_ops",
  "PathPrefix": "arch/arm64/kvm/vgic/vgic-its.c"
}

{
  "Output": "arch/arm64/kvm/vgic/vgic-its.c-25-\narch/arm64/kvm/vgic/vgic-its.c:26:static struct kvm_device_ops kvm_arm_vgic_its_ops;\narch/arm64/kvm/vgic/vgic-its.c-27-\n--\narch/arm64/kvm/vgic/vgic-its.c=619=void vgic_its_invalidate_all_caches(struct kvm *kvm)\n--\narch/arm64/kvm/vgic/vgic-its.c-626-\tlist_for_each_entry_rcu(dev, \u0026kvm-\u003edevices, vm_node) {\narch/arm64/kvm/vgic/vgic-its.c:627:\t\tif (dev-\u003eops != \u0026kvm_arm_vgic_its_ops)\narch/arm64/kvm/vgic/vgic-its.c-628-\t\t\tcontinue;\n--\narch/arm64/kvm/vgic/vgic-its.c=2794=static int vgic_its_get_attr(struct kvm_device *dev,\n--\narch/arm64/kvm/vgic/vgic-its.c-2827-\narch/arm64/kvm/vgic/vgic-its.c:2828:static struct kvm_device_ops kvm_arm_vgic_its_ops = {\narch/arm64/kvm/vgic/vgic-its.c-2829-\t.name = \"kvm-arm-vgic-its\",\n--\narch/arm64/kvm/vgic/vgic-its.c=2837=int kvm_vgic_register_its_device(void)\narch/arm64/kvm/vgic/vgic-its.c-2838-{\narch/arm64/kvm/vgic/vgic-its.c:2839:\treturn kvm_register_device_ops(\u0026kvm_arm_vgic_its_ops,\narch/arm64/kvm/vgic/vgic-its.c-2840-\t\t\t\t       KVM_DEV_TYPE_ARM_VGIC_ITS);\n"
}

gemini-3.1-pro-preview

null

null

							input: 6932
							output: 46
							thoughts: 291
						

**Analyzing KVM ITS Device Callbacks for Exploitation**

Okay, so I'm looking at these callbacks: `vgic_its_set_attr`, `vgic_its_destroy`, `vgic_its_create`, `vgic_its_has_attr`, and `vgic_its_get_attr`. They're all declared as `static`, which initially makes me think they'd be harder to target directly. But then I remember: these functions are part of the `kvm_device_ops` structure, and those callbacks are called from generic KVM code via function pointers. That's key.

If they were inlined, the `static` declaration *would* be a problem. Targeting them by name would be difficult. But since they're function pointers, they *aren't* inlined. The compiler has to provide a real address for them. And that opens up possibilities.

The beauty of syzkaller is that it can target ioctls, like `KVM_SET_DEVICE_ATTR`, which will eventually reach `vgic_its_set_attr`. That's a direct route. Now, are there any *non-static* functions that might be easier to leverage? I see `kvm_vgic_register_its_device`, but that's just registration, so likely not interesting from an exploit perspective.

Focusing back on `vgic_its_set_attr` and `vgic_its_destroy`… even though they're `static`, the function pointer usage changes everything. Syzkaller *can* target static functions if they're not inlined, and their addresses *are* taken, which means they're not inlined.

So, the plan is: we can definitely use `vgic_its_set_attr` and `vgic_its_destroy`. Let's just double-check that they are, in fact, static functions. We need to be absolutely sure.

{
  "Expression": "vgic_its_set_attr",
  "PathPrefix": "arch/arm64/kvm/vgic/vgic-its.c"
}

{
  "Output": "arch/arm64/kvm/vgic/vgic-its.c=2742=bool kvm_arch_allow_write_without_running_vcpu(struct kvm *kvm)\n--\narch/arm64/kvm/vgic/vgic-its.c-2748-\narch/arm64/kvm/vgic/vgic-its.c:2749:static int vgic_its_set_attr(struct kvm_device *dev,\narch/arm64/kvm/vgic/vgic-its.c-2750-\t\t\t     struct kvm_device_attr *attr)\n--\narch/arm64/kvm/vgic/vgic-its.c=2828=static struct kvm_device_ops kvm_arm_vgic_its_ops = {\n--\narch/arm64/kvm/vgic/vgic-its.c-2831-\t.destroy = vgic_its_destroy,\narch/arm64/kvm/vgic/vgic-its.c:2832:\t.set_attr = vgic_its_set_attr,\narch/arm64/kvm/vgic/vgic-its.c-2833-\t.get_attr = vgic_its_get_attr,\n"
}

gemini-3.1-pro-preview

null

null

							input: 8025
							output: 39
							thoughts: 81
						

Okay, let's see, my initial impression is that these functions seem to be *static* which isn't ideal for an entry point. The question then becomes, is there a non-static function that might serve a better purpose? Let me think, *vgic_its_destroy* is definitely out, being static. Hm, what about *vgic_mmio_write_its_baser*? That's also static... but wait, it appears to be called from *vgic_mmio_write*. Okay, *vgic_mmio_write* is non-static, so let's dig into that and confirm the call graph.

{
  "Expression": "vgic_mmio_write",
  "PathPrefix": "arch/arm64/kvm/vgic/"
}

{
  "Output": "\nFull output is too long, showing 500 out of 503 lines.\nUse more precise expression if possible.\n\narch/arm64/kvm/vgic/vgic-its.c=1511=static unsigned long vgic_mmio_read_its_cbaser(struct kvm *kvm,\n--\narch/arm64/kvm/vgic/vgic-its.c-1517-\narch/arm64/kvm/vgic/vgic-its.c:1518:static void vgic_mmio_write_its_cbaser(struct kvm *kvm, struct vgic_its *its,\narch/arm64/kvm/vgic/vgic-its.c-1519-\t\t\t\t       gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-its.c=1543=static void vgic_its_process_commands(struct kvm *kvm, struct vgic_its *its)\n--\narch/arm64/kvm/vgic/vgic-its.c-1578- */\narch/arm64/kvm/vgic/vgic-its.c:1579:static void vgic_mmio_write_its_cwriter(struct kvm *kvm, struct vgic_its *its,\narch/arm64/kvm/vgic/vgic-its.c-1580-\t\t\t\t\tgpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-its.c=1645=static unsigned long vgic_mmio_read_its_baser(struct kvm *kvm,\n--\narch/arm64/kvm/vgic/vgic-its.c-1666-#define GITS_BASER_RO_MASK\t(GENMASK_ULL(52, 48) | GENMASK_ULL(58, 56))\narch/arm64/kvm/vgic/vgic-its.c:1667:static void vgic_mmio_write_its_baser(struct kvm *kvm,\narch/arm64/kvm/vgic/vgic-its.c-1668-\t\t\t\t      struct vgic_its *its,\n--\narch/arm64/kvm/vgic/vgic-its.c=1721=static unsigned long vgic_mmio_read_its_ctlr(struct kvm *vcpu,\n--\narch/arm64/kvm/vgic/vgic-its.c-1736-\narch/arm64/kvm/vgic/vgic-its.c:1737:static void vgic_mmio_write_its_ctlr(struct kvm *kvm, struct vgic_its *its,\narch/arm64/kvm/vgic/vgic-its.c-1738-\t\t\t\t     gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-its.c=1792=static struct vgic_register_region its_registers[] = {\narch/arm64/kvm/vgic/vgic-its.c-1793-\tREGISTER_ITS_DESC(GITS_CTLR,\narch/arm64/kvm/vgic/vgic-its.c:1794:\t\tvgic_mmio_read_its_ctlr, vgic_mmio_write_its_ctlr, 4,\narch/arm64/kvm/vgic/vgic-its.c-1795-\t\tVGIC_ACCESS_32bit),\n--\narch/arm64/kvm/vgic/vgic-its.c-1803-\tREGISTER_ITS_DESC(GITS_CBASER,\narch/arm64/kvm/vgic/vgic-its.c:1804:\t\tvgic_mmio_read_its_cbaser, vgic_mmio_write_its_cbaser, 8,\narch/arm64/kvm/vgic/vgic-its.c-1805-\t\tVGIC_ACCESS_64bit | VGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-its.c-1806-\tREGISTER_ITS_DESC(GITS_CWRITER,\narch/arm64/kvm/vgic/vgic-its.c:1807:\t\tvgic_mmio_read_its_cwriter, vgic_mmio_write_its_cwriter, 8,\narch/arm64/kvm/vgic/vgic-its.c-1808-\t\tVGIC_ACCESS_64bit | VGIC_ACCESS_32bit),\n--\narch/arm64/kvm/vgic/vgic-its.c-1813-\tREGISTER_ITS_DESC(GITS_BASER,\narch/arm64/kvm/vgic/vgic-its.c:1814:\t\tvgic_mmio_read_its_baser, vgic_mmio_write_its_baser, 0x40,\narch/arm64/kvm/vgic/vgic-its.c-1815-\t\tVGIC_ACCESS_64bit | VGIC_ACCESS_32bit),\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c=25=static unsigned long vgic_mmio_read_v2_misc(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c-51-\narch/arm64/kvm/vgic/vgic-mmio-v2.c:52:static void vgic_mmio_write_v2_misc(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-53-\t\t\t\t    gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c=72=static int vgic_mmio_uaccess_write_v2_misc(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c-105-\narch/arm64/kvm/vgic/vgic-mmio-v2.c:106:\tvgic_mmio_write_v2_misc(vcpu, addr, len, val);\narch/arm64/kvm/vgic/vgic-mmio-v2.c-107-\treturn 0;\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c=110=static int vgic_mmio_uaccess_write_v2_group(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c-114-\tif (vcpu-\u003ekvm-\u003earch.vgic.v2_groups_user_writable)\narch/arm64/kvm/vgic/vgic-mmio-v2.c:115:\t\tvgic_mmio_write_group(vcpu, addr, len, val);\narch/arm64/kvm/vgic/vgic-mmio-v2.c-116-\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c-119-\narch/arm64/kvm/vgic/vgic-mmio-v2.c:120:static void vgic_mmio_write_sgir(struct kvm_vcpu *source_vcpu,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-121-\t\t\t\t gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c=162=static unsigned long vgic_mmio_read_target(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c-179-\narch/arm64/kvm/vgic/vgic-mmio-v2.c:180:static void vgic_mmio_write_target(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-181-\t\t\t\t   gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c=208=static unsigned long vgic_mmio_read_sgipend(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c-224-\narch/arm64/kvm/vgic/vgic-mmio-v2.c:225:static void vgic_mmio_write_sgipendc(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-226-\t\t\t\t     gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c-246-\narch/arm64/kvm/vgic/vgic-mmio-v2.c:247:static void vgic_mmio_write_sgipends(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-248-\t\t\t\t     gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c=275=static unsigned long vgic_mmio_read_vcpuif(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c-321-\narch/arm64/kvm/vgic/vgic-mmio-v2.c:322:static void vgic_mmio_write_vcpuif(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-323-\t\t\t\t   gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c-361-\narch/arm64/kvm/vgic/vgic-mmio-v2.c:362:static void vgic_mmio_write_dir(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-363-\t\t\t\tgpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c=372=static unsigned long vgic_mmio_read_apr(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c-396-\narch/arm64/kvm/vgic/vgic-mmio-v2.c:397:static void vgic_mmio_write_apr(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-398-\t\t\t\tgpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c=423=static const struct vgic_register_region vgic_v2_dist_registers[] = {\narch/arm64/kvm/vgic/vgic-mmio-v2.c-424-\tREGISTER_DESC_WITH_LENGTH_UACCESS(GIC_DIST_CTRL,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:425:\t\tvgic_mmio_read_v2_misc, vgic_mmio_write_v2_misc,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-426-\t\tNULL, vgic_mmio_uaccess_write_v2_misc,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c-428-\tREGISTER_DESC_WITH_BITS_PER_IRQ(GIC_DIST_IGROUP,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:429:\t\tvgic_mmio_read_group, vgic_mmio_write_group,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-430-\t\tNULL, vgic_mmio_uaccess_write_v2_group, 1,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c-432-\tREGISTER_DESC_WITH_BITS_PER_IRQ(GIC_DIST_ENABLE_SET,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:433:\t\tvgic_mmio_read_enable, vgic_mmio_write_senable,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-434-\t\tNULL, vgic_uaccess_write_senable, 1,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c-436-\tREGISTER_DESC_WITH_BITS_PER_IRQ(GIC_DIST_ENABLE_CLEAR,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:437:\t\tvgic_mmio_read_enable, vgic_mmio_write_cenable,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-438-\t\tNULL, vgic_uaccess_write_cenable, 1,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c-440-\tREGISTER_DESC_WITH_BITS_PER_IRQ(GIC_DIST_PENDING_SET,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:441:\t\tvgic_mmio_read_pending, vgic_mmio_write_spending,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-442-\t\tvgic_uaccess_read_pending, vgic_uaccess_write_spending, 1,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c-444-\tREGISTER_DESC_WITH_BITS_PER_IRQ(GIC_DIST_PENDING_CLEAR,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:445:\t\tvgic_mmio_read_pending, vgic_mmio_write_cpending,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-446-\t\tvgic_uaccess_read_pending, vgic_uaccess_write_cpending, 1,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c-448-\tREGISTER_DESC_WITH_BITS_PER_IRQ(GIC_DIST_ACTIVE_SET,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:449:\t\tvgic_mmio_read_active, vgic_mmio_write_sactive,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-450-\t\tvgic_uaccess_read_active, vgic_mmio_uaccess_write_sactive, 1,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c-452-\tREGISTER_DESC_WITH_BITS_PER_IRQ(GIC_DIST_ACTIVE_CLEAR,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:453:\t\tvgic_mmio_read_active, vgic_mmio_write_cactive,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-454-\t\tvgic_uaccess_read_active, vgic_mmio_uaccess_write_cactive, 1,\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c-456-\tREGISTER_DESC_WITH_BITS_PER_IRQ(GIC_DIST_PRI,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:457:\t\tvgic_mmio_read_priority, vgic_mmio_write_priority, NULL, NULL,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-458-\t\t8, VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),\narch/arm64/kvm/vgic/vgic-mmio-v2.c-459-\tREGISTER_DESC_WITH_BITS_PER_IRQ(GIC_DIST_TARGET,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:460:\t\tvgic_mmio_read_target, vgic_mmio_write_target, NULL, NULL, 8,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-461-\t\tVGIC_ACCESS_32bit | VGIC_ACCESS_8bit),\narch/arm64/kvm/vgic/vgic-mmio-v2.c-462-\tREGISTER_DESC_WITH_BITS_PER_IRQ(GIC_DIST_CONFIG,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:463:\t\tvgic_mmio_read_config, vgic_mmio_write_config, NULL, NULL, 2,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-464-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v2.c-465-\tREGISTER_DESC_WITH_LENGTH(GIC_DIST_SOFTINT,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:466:\t\tvgic_mmio_read_raz, vgic_mmio_write_sgir, 4,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-467-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v2.c-468-\tREGISTER_DESC_WITH_LENGTH(GIC_DIST_SGI_PENDING_CLEAR,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:469:\t\tvgic_mmio_read_sgipend, vgic_mmio_write_sgipendc, 16,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-470-\t\tVGIC_ACCESS_32bit | VGIC_ACCESS_8bit),\narch/arm64/kvm/vgic/vgic-mmio-v2.c-471-\tREGISTER_DESC_WITH_LENGTH(GIC_DIST_SGI_PENDING_SET,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:472:\t\tvgic_mmio_read_sgipend, vgic_mmio_write_sgipends, 16,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-473-\t\tVGIC_ACCESS_32bit | VGIC_ACCESS_8bit),\n--\narch/arm64/kvm/vgic/vgic-mmio-v2.c=476=static const struct vgic_register_region vgic_v2_cpu_registers[] = {\narch/arm64/kvm/vgic/vgic-mmio-v2.c-477-\tREGISTER_DESC_WITH_LENGTH(GIC_CPU_CTRL,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:478:\t\tvgic_mmio_read_vcpuif, vgic_mmio_write_vcpuif, 4,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-479-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v2.c-480-\tREGISTER_DESC_WITH_LENGTH(GIC_CPU_PRIMASK,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:481:\t\tvgic_mmio_read_vcpuif, vgic_mmio_write_vcpuif, 4,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-482-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v2.c-483-\tREGISTER_DESC_WITH_LENGTH(GIC_CPU_BINPOINT,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:484:\t\tvgic_mmio_read_vcpuif, vgic_mmio_write_vcpuif, 4,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-485-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v2.c-486-\tREGISTER_DESC_WITH_LENGTH(GIC_CPU_ALIAS_BINPOINT,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:487:\t\tvgic_mmio_read_vcpuif, vgic_mmio_write_vcpuif, 4,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-488-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v2.c-489-\tREGISTER_DESC_WITH_LENGTH(GIC_CPU_ACTIVEPRIO,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:490:\t\tvgic_mmio_read_apr, vgic_mmio_write_apr, 16,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-491-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v2.c-492-\tREGISTER_DESC_WITH_LENGTH(GIC_CPU_IDENT,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:493:\t\tvgic_mmio_read_vcpuif, vgic_mmio_write_vcpuif, 4,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-494-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v2.c-495-\tREGISTER_DESC_WITH_LENGTH_UACCESS(GIC_CPU_DEACTIVATE,\narch/arm64/kvm/vgic/vgic-mmio-v2.c:496:\t\tvgic_mmio_read_raz, vgic_mmio_write_dir,\narch/arm64/kvm/vgic/vgic-mmio-v2.c-497-\t\tvgic_mmio_read_raz, vgic_mmio_uaccess_write_wi,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c=81=static unsigned long vgic_mmio_read_v3_misc(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-120-\narch/arm64/kvm/vgic/vgic-mmio-v3.c:121:static void vgic_mmio_write_v3_misc(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-122-\t\t\t\t    gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c=170=static int vgic_mmio_uaccess_write_v3_misc(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-215-\narch/arm64/kvm/vgic/vgic-mmio-v3.c:216:\tvgic_mmio_write_v3_misc(vcpu, addr, len, val);\narch/arm64/kvm/vgic/vgic-mmio-v3.c-217-\treturn 0;\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c=220=static unsigned long vgic_mmio_read_irouter(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-237-\narch/arm64/kvm/vgic/vgic-mmio-v3.c:238:static void vgic_mmio_write_irouter(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-239-\t\t\t\t    gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c=272=static unsigned long vgic_mmio_read_v3r_ctlr(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-284-\narch/arm64/kvm/vgic/vgic-mmio-v3.c:285:static void vgic_mmio_write_v3r_ctlr(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-286-\t\t\t\t     gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c=479=static unsigned long vgic_mmio_read_propbase(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-486-\narch/arm64/kvm/vgic/vgic-mmio-v3.c:487:static void vgic_mmio_write_propbase(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-488-\t\t\t\t     gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c=507=static unsigned long vgic_mmio_read_pendbase(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-517-\narch/arm64/kvm/vgic/vgic-mmio-v3.c:518:static void vgic_mmio_write_pendbase(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-519-\t\t\t\t     gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c=544=static void vgic_set_rdist_busy(struct kvm_vcpu *vcpu, bool busy)\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-554-\narch/arm64/kvm/vgic/vgic-mmio-v3.c:555:static void vgic_mmio_write_invlpi(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-556-\t\t\t\t   gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-586-\narch/arm64/kvm/vgic/vgic-mmio-v3.c:587:static void vgic_mmio_write_invall(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-588-\t\t\t\t   gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-590-{\narch/arm64/kvm/vgic/vgic-mmio-v3.c:591:\t/* See vgic_mmio_write_invlpi() for the early return rationale */\narch/arm64/kvm/vgic/vgic-mmio-v3.c-592-\tif ((addr \u0026 4) || !vgic_lpis_enabled(vcpu))\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-613-\t\t.read = vgic_mmio_read_raz,\t\t\t\t\\\narch/arm64/kvm/vgic/vgic-mmio-v3.c:614:\t\t.write = vgic_mmio_write_wi,\t\t\t\t\\\narch/arm64/kvm/vgic/vgic-mmio-v3.c-615-\t}, {\t\t\t\t\t\t\t\t\\\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c=626=static const struct vgic_register_region vgic_v3_dist_registers[] = {\narch/arm64/kvm/vgic/vgic-mmio-v3.c-627-\tREGISTER_DESC_WITH_LENGTH_UACCESS(GICD_CTLR,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:628:\t\tvgic_mmio_read_v3_misc, vgic_mmio_write_v3_misc,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-629-\t\tNULL, vgic_mmio_uaccess_write_v3_misc,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-631-\tREGISTER_DESC_WITH_LENGTH(GICD_STATUSR,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:632:\t\tvgic_mmio_read_rao, vgic_mmio_write_wi, 4,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-633-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-634-\tREGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_IGROUPR,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:635:\t\tvgic_mmio_read_group, vgic_mmio_write_group, NULL, NULL, 1,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-636-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-637-\tREGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ISENABLER,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:638:\t\tvgic_mmio_read_enable, vgic_mmio_write_senable,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-639-\t\tNULL, vgic_uaccess_write_senable, 1,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-641-\tREGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ICENABLER,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:642:\t\tvgic_mmio_read_enable, vgic_mmio_write_cenable,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-643-\t       NULL, vgic_uaccess_write_cenable, 1,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-645-\tREGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ISPENDR,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:646:\t\tvgic_mmio_read_pending, vgic_mmio_write_spending,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-647-\t\tvgic_uaccess_read_pending, vgic_v3_uaccess_write_pending, 1,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-649-\tREGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ICPENDR,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:650:\t\tvgic_mmio_read_pending, vgic_mmio_write_cpending,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-651-\t\tvgic_mmio_read_raz, vgic_mmio_uaccess_write_wi, 1,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-653-\tREGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ISACTIVER,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:654:\t\tvgic_mmio_read_active, vgic_mmio_write_sactive,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-655-\t\tvgic_uaccess_read_active, vgic_mmio_uaccess_write_sactive, 1,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-657-\tREGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ICACTIVER,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:658:\t\tvgic_mmio_read_active, vgic_mmio_write_cactive,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-659-\t\tvgic_uaccess_read_active, vgic_mmio_uaccess_write_cactive,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-661-\tREGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_IPRIORITYR,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:662:\t\tvgic_mmio_read_priority, vgic_mmio_write_priority, NULL, NULL,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-663-\t\t8, VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-664-\tREGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ITARGETSR,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:665:\t\tvgic_mmio_read_raz, vgic_mmio_write_wi, NULL, NULL, 8,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-666-\t\tVGIC_ACCESS_32bit | VGIC_ACCESS_8bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-667-\tREGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ICFGR,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:668:\t\tvgic_mmio_read_config, vgic_mmio_write_config, NULL, NULL, 2,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-669-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-670-\tREGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_IGRPMODR,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:671:\t\tvgic_mmio_read_raz, vgic_mmio_write_wi, NULL, NULL, 1,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-672-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-673-\tREGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_IROUTER,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:674:\t\tvgic_mmio_read_irouter, vgic_mmio_write_irouter, NULL, NULL, 64,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-675-\t\tVGIC_ACCESS_64bit | VGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-676-\tREGISTER_DESC_WITH_LENGTH(GICD_IDREGS,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:677:\t\tvgic_mmio_read_v3_idregs, vgic_mmio_write_wi, 48,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-678-\t\tVGIC_ACCESS_32bit),\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c=681=static const struct vgic_register_region vgic_v3_rd_registers[] = {\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-683-\tREGISTER_DESC_WITH_LENGTH(GICR_CTLR,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:684:\t\tvgic_mmio_read_v3r_ctlr, vgic_mmio_write_v3r_ctlr, 4,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-685-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-686-\tREGISTER_DESC_WITH_LENGTH(GICR_STATUSR,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:687:\t\tvgic_mmio_read_raz, vgic_mmio_write_wi, 4,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-688-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-689-\tREGISTER_DESC_WITH_LENGTH(GICR_IIDR,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:690:\t\tvgic_mmio_read_v3r_iidr, vgic_mmio_write_wi, 4,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-691-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-692-\tREGISTER_DESC_WITH_LENGTH_UACCESS(GICR_TYPER,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:693:\t\tvgic_mmio_read_v3r_typer, vgic_mmio_write_wi,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-694-\t\tNULL, vgic_mmio_uaccess_write_wi, 8,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-696-\tREGISTER_DESC_WITH_LENGTH(GICR_WAKER,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:697:\t\tvgic_mmio_read_raz, vgic_mmio_write_wi, 4,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-698-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-699-\tREGISTER_DESC_WITH_LENGTH(GICR_PROPBASER,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:700:\t\tvgic_mmio_read_propbase, vgic_mmio_write_propbase, 8,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-701-\t\tVGIC_ACCESS_64bit | VGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-702-\tREGISTER_DESC_WITH_LENGTH(GICR_PENDBASER,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:703:\t\tvgic_mmio_read_pendbase, vgic_mmio_write_pendbase, 8,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-704-\t\tVGIC_ACCESS_64bit | VGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-705-\tREGISTER_DESC_WITH_LENGTH(GICR_INVLPIR,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:706:\t\tvgic_mmio_read_raz, vgic_mmio_write_invlpi, 8,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-707-\t\tVGIC_ACCESS_64bit | VGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-708-\tREGISTER_DESC_WITH_LENGTH(GICR_INVALLR,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:709:\t\tvgic_mmio_read_raz, vgic_mmio_write_invall, 8,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-710-\t\tVGIC_ACCESS_64bit | VGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-711-\tREGISTER_DESC_WITH_LENGTH(GICR_SYNCR,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:712:\t\tvgic_mmio_read_sync, vgic_mmio_write_wi, 4,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-713-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-714-\tREGISTER_DESC_WITH_LENGTH(GICR_IDREGS,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:715:\t\tvgic_mmio_read_v3_idregs, vgic_mmio_write_wi, 48,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-716-\t\tVGIC_ACCESS_32bit),\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-718-\tREGISTER_DESC_WITH_LENGTH(SZ_64K + GICR_IGROUPR0,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:719:\t\tvgic_mmio_read_group, vgic_mmio_write_group, 4,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-720-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-721-\tREGISTER_DESC_WITH_LENGTH_UACCESS(SZ_64K + GICR_ISENABLER0,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:722:\t\tvgic_mmio_read_enable, vgic_mmio_write_senable,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-723-\t\tNULL, vgic_uaccess_write_senable, 4,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-725-\tREGISTER_DESC_WITH_LENGTH_UACCESS(SZ_64K + GICR_ICENABLER0,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:726:\t\tvgic_mmio_read_enable, vgic_mmio_write_cenable,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-727-\t\tNULL, vgic_uaccess_write_cenable, 4,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-729-\tREGISTER_DESC_WITH_LENGTH_UACCESS(SZ_64K + GICR_ISPENDR0,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:730:\t\tvgic_mmio_read_pending, vgic_mmio_write_spending,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-731-\t\tvgic_uaccess_read_pending, vgic_v3_uaccess_write_pending, 4,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-733-\tREGISTER_DESC_WITH_LENGTH_UACCESS(SZ_64K + GICR_ICPENDR0,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:734:\t\tvgic_mmio_read_pending, vgic_mmio_write_cpending,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-735-\t\tvgic_mmio_read_raz, vgic_mmio_uaccess_write_wi, 4,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-737-\tREGISTER_DESC_WITH_LENGTH_UACCESS(SZ_64K + GICR_ISACTIVER0,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:738:\t\tvgic_mmio_read_active, vgic_mmio_write_sactive,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-739-\t\tvgic_uaccess_read_active, vgic_mmio_uaccess_write_sactive, 4,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-741-\tREGISTER_DESC_WITH_LENGTH_UACCESS(SZ_64K + GICR_ICACTIVER0,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:742:\t\tvgic_mmio_read_active, vgic_mmio_write_cactive,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-743-\t\tvgic_uaccess_read_active, vgic_mmio_uaccess_write_cactive, 4,\n--\narch/arm64/kvm/vgic/vgic-mmio-v3.c-745-\tREGISTER_DESC_WITH_LENGTH(SZ_64K + GICR_IPRIORITYR0,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:746:\t\tvgic_mmio_read_priority, vgic_mmio_write_priority, 32,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-747-\t\tVGIC_ACCESS_32bit | VGIC_ACCESS_8bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-748-\tREGISTER_DESC_WITH_LENGTH(SZ_64K + GICR_ICFGR0,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:749:\t\tvgic_mmio_read_config, vgic_mmio_write_config, 8,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-750-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-751-\tREGISTER_DESC_WITH_LENGTH(SZ_64K + GICR_IGRPMODR0,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:752:\t\tvgic_mmio_read_raz, vgic_mmio_write_wi, 4,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-753-\t\tVGIC_ACCESS_32bit),\narch/arm64/kvm/vgic/vgic-mmio-v3.c-754-\tREGISTER_DESC_WITH_LENGTH(SZ_64K + GICR_NSACR,\narch/arm64/kvm/vgic/vgic-mmio-v3.c:755:\t\tvgic_mmio_read_raz, vgic_mmio_write_wi, 4,\narch/arm64/kvm/vgic/vgic-mmio-v3.c-756-\t\tVGIC_ACCESS_32bit),\n--\narch/arm64/kvm/vgic/vgic-mmio.c=25=unsigned long vgic_mmio_read_rao(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-30-\narch/arm64/kvm/vgic/vgic-mmio.c:31:void vgic_mmio_write_wi(struct kvm_vcpu *vcpu, gpa_t addr,\narch/arm64/kvm/vgic/vgic-mmio.c-32-\t\t\tunsigned int len, unsigned long val)\n--\narch/arm64/kvm/vgic/vgic-mmio.c=64=static void vgic_update_vsgi(struct vgic_irq *irq)\n--\narch/arm64/kvm/vgic/vgic-mmio.c-68-\narch/arm64/kvm/vgic/vgic-mmio.c:69:void vgic_mmio_write_group(struct kvm_vcpu *vcpu, gpa_t addr,\narch/arm64/kvm/vgic/vgic-mmio.c-70-\t\t\t   unsigned int len, unsigned long val)\n--\narch/arm64/kvm/vgic/vgic-mmio.c=96=unsigned long vgic_mmio_read_enable(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-115-\narch/arm64/kvm/vgic/vgic-mmio.c:116:void vgic_mmio_write_senable(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-117-\t\t\t     gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-164-\narch/arm64/kvm/vgic/vgic-mmio.c:165:void vgic_mmio_write_cenable(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-166-\t\t\t     gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c=304=static void __set_pending(struct kvm_vcpu *vcpu, gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-352-\narch/arm64/kvm/vgic/vgic-mmio.c:353:void vgic_mmio_write_spending(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-354-\t\t\t      gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c=389=static void __clear_pending(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-439-\narch/arm64/kvm/vgic/vgic-mmio.c:440:void vgic_mmio_write_cpending(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-441-\t\t\t      gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c=546=static void vgic_mmio_change_active(struct kvm_vcpu *vcpu, struct vgic_irq *irq,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-592-\narch/arm64/kvm/vgic/vgic-mmio.c:593:static void __vgic_mmio_write_cactive(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-594-\t\t\t\t      gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-606-\narch/arm64/kvm/vgic/vgic-mmio.c:607:void vgic_mmio_write_cactive(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-608-\t\t\t     gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-615-\narch/arm64/kvm/vgic/vgic-mmio.c:616:\t__vgic_mmio_write_cactive(vcpu, addr, len, val);\narch/arm64/kvm/vgic/vgic-mmio.c-617-\n--\narch/arm64/kvm/vgic/vgic-mmio.c=622=int vgic_mmio_uaccess_write_cactive(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-625-{\narch/arm64/kvm/vgic/vgic-mmio.c:626:\t__vgic_mmio_write_cactive(vcpu, addr, len, val);\narch/arm64/kvm/vgic/vgic-mmio.c-627-\treturn 0;\n--\narch/arm64/kvm/vgic/vgic-mmio.c-629-\narch/arm64/kvm/vgic/vgic-mmio.c:630:static void __vgic_mmio_write_sactive(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-631-\t\t\t\t      gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-643-\narch/arm64/kvm/vgic/vgic-mmio.c:644:void vgic_mmio_write_sactive(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-645-\t\t\t     gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-652-\narch/arm64/kvm/vgic/vgic-mmio.c:653:\t__vgic_mmio_write_sactive(vcpu, addr, len, val);\narch/arm64/kvm/vgic/vgic-mmio.c-654-\n--\narch/arm64/kvm/vgic/vgic-mmio.c=659=int vgic_mmio_uaccess_write_sactive(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-662-{\narch/arm64/kvm/vgic/vgic-mmio.c:663:\t__vgic_mmio_write_sactive(vcpu, addr, len, val);\narch/arm64/kvm/vgic/vgic-mmio.c-664-\treturn 0;\n--\narch/arm64/kvm/vgic/vgic-mmio.c=667=unsigned long vgic_mmio_read_priority(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-691- */\narch/arm64/kvm/vgic/vgic-mmio.c:692:void vgic_mmio_write_priority(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-693-\t\t\t      gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c=714=unsigned long vgic_mmio_read_config(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-732-\narch/arm64/kvm/vgic/vgic-mmio.c:733:void vgic_mmio_write_config(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-734-\t\t\t    gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.h=115=unsigned long vgic_mmio_read_rao(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.h-117-\narch/arm64/kvm/vgic/vgic-mmio.h:118:void vgic_mmio_write_wi(struct kvm_vcpu *vcpu, gpa_t addr,\narch/arm64/kvm/vgic/vgic-mmio.h-119-\t\t\tunsigned int len, unsigned long val);\n--\narch/arm64/kvm/vgic/vgic-mmio.h=124=unsigned long vgic_mmio_read_group(struct kvm_vcpu *vcpu, gpa_t addr,\n--\narch/arm64/kvm/vgic/vgic-mmio.h-126-\narch/arm64/kvm/vgic/vgic-mmio.h:127:void vgic_mmio_write_group(struct kvm_vcpu *vcpu, gpa_t addr,\narch/arm64/kvm/vgic/vgic-mmio.h-128-\t\t\t   unsigned int len, unsigned long val);\n--\narch/arm64/kvm/vgic/vgic-mmio.h=130=unsigned long vgic_mmio_read_enable(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.h-132-\narch/arm64/kvm/vgic/vgic-mmio.h:133:void vgic_mmio_write_senable(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.h-134-\t\t\t     gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.h-136-\narch/arm64/kvm/vgic/vgic-mmio.h:137:void vgic_mmio_write_cenable(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.h-138-\t\t\t     gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.h=152=unsigned long vgic_uaccess_read_pending(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.h-154-\narch/arm64/kvm/vgic/vgic-mmio.h:155:void vgic_mmio_write_spending(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.h-156-\t\t\t      gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.h-158-\narch/arm64/kvm/vgic/vgic-mmio.h:159:void vgic_mmio_write_cpending(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.h-160-\t\t\t      gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.h=174=unsigned long vgic_uaccess_read_active(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.h-176-\narch/arm64/kvm/vgic/vgic-mmio.h:177:void vgic_mmio_write_cactive(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.h-178-\t\t\t     gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.h-180-\narch/arm64/kvm/vgic/vgic-mmio.h:181:void vgic_mmio_write_sactive(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.h-182-\t\t\t     gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.h=193=unsigned long vgic_mmio_read_priority(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.h-195-\narch/arm64/kvm/vgic/vgic-mmio.h:196:void vgic_mmio_write_priority(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.h-197-\t\t\t      gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.h=200=unsigned long vgic_mmio_read_config(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.h-202-\narch/arm64/kvm/vgic/vgic-mmio.h:203:void vgic_mmio_write_config(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.h-204-\t\t\t    gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-v2.c=151=void vgic_v2_deactivate(struct kvm_vcpu *vcpu, u32 val)\n--\narch/arm64/kvm/vgic/vgic-v2.c-216-\tif (mmio)\narch/arm64/kvm/vgic/vgic-v2.c:217:\t\tvgic_mmio_write_cactive(vcpu, (val / 32) * 4, 4, BIT(val % 32));\narch/arm64/kvm/vgic/vgic-v2.c-218-\n--\narch/arm64/kvm/vgic/vgic-v3.c=195=void vgic_v3_deactivate(struct kvm_vcpu *vcpu, u64 val)\n--\n\n"
}

gemini-3.1-pro-preview

null

null

							input: 25537
							output: 61
							thoughts: 202
						

**Analyzing Potential Security Risks in the ITS Code**

Okay, so I'm looking at this `vgic_mmio_write_its_baser` function. It's static, which is the first point of note. Now, the next logical question is whether any non-static function calls the memory management function `vgic_its_free_collection_list`. Nope, that one's static too. Just to be thorough, I check the obvious candidates: `vgic_its_destroy`? Also static.

Alright, what about `kvm_vgic_register_its_device`? Aha! That one's non-static. The key here is that Syzkaller is capable of targeting those `kvm_device_ops` callbacks through KVM ioctls. Since `vgic_its_destroy` and `vgic_its_set_attr` are static but their addresses are being taken (meaning they're not inlined), they're potential targets. This is important because Syzkaller really goes to town fuzzing these KVM ioctls.

Given the potential attack surface, I need to see what else might be vulnerable. It's time to systematically review all the non-static functions within `arch/arm64/kvm/vgic/vgic-its.c`. This is where the real vulnerabilities might be lurking. Time to dive in!

{
  "Expression": "^[a-zA-Z_][a-zA-Z0-9_]* vgic_its_",
  "PathPrefix": "arch/arm64/kvm/vgic/vgic-its.c"
}

{
  "Output": "arch/arm64/kvm/vgic/vgic-its.c=76=static struct vgic_irq *vgic_add_lpi(struct kvm *kvm, u32 intid,\n--\narch/arm64/kvm/vgic/vgic-its.c-173- */\narch/arm64/kvm/vgic/vgic-its.c:174:struct vgic_its_abi {\narch/arm64/kvm/vgic/vgic-its.c-175-\tint cte_esz;\n--\narch/arm64/kvm/vgic/vgic-its.c=605=static void vgic_its_invalidate_cache(struct vgic_its *its)\n--\narch/arm64/kvm/vgic/vgic-its.c-618-\narch/arm64/kvm/vgic/vgic-its.c:619:void vgic_its_invalidate_all_caches(struct kvm *kvm)\narch/arm64/kvm/vgic/vgic-its.c-620-{\n--\narch/arm64/kvm/vgic/vgic-its.c-636-\narch/arm64/kvm/vgic/vgic-its.c:637:int vgic_its_resolve_lpi(struct kvm *kvm, struct vgic_its *its,\narch/arm64/kvm/vgic/vgic-its.c-638-\t\t\t u32 devid, u32 eventid, struct vgic_irq **irq)\n--\narch/arm64/kvm/vgic/vgic-its.c=685=static int vgic_its_trigger_msi(struct kvm *kvm, struct vgic_its *its,\n--\narch/arm64/kvm/vgic/vgic-its.c-706-\narch/arm64/kvm/vgic/vgic-its.c:707:int vgic_its_inject_cached_translation(struct kvm *kvm, struct kvm_msi *msi)\narch/arm64/kvm/vgic/vgic-its.c-708-{\n--\narch/arm64/kvm/vgic/vgic-its.c-731- */\narch/arm64/kvm/vgic/vgic-its.c:732:int vgic_its_inject_msi(struct kvm *kvm, struct kvm_msi *msi)\narch/arm64/kvm/vgic/vgic-its.c-733-{\n--\narch/arm64/kvm/vgic/vgic-its.c=1267=static int vgic_its_cmd_handle_clear(struct kvm *kvm, struct vgic_its *its,\n--\narch/arm64/kvm/vgic/vgic-its.c-1287-\narch/arm64/kvm/vgic/vgic-its.c:1288:int vgic_its_inv_lpi(struct kvm *kvm, struct vgic_irq *irq)\narch/arm64/kvm/vgic/vgic-its.c-1289-{\n--\narch/arm64/kvm/vgic/vgic-its.c=1297=static int vgic_its_cmd_handle_inv(struct kvm *kvm, struct vgic_its *its,\n--\narch/arm64/kvm/vgic/vgic-its.c-1319- */\narch/arm64/kvm/vgic/vgic-its.c:1320:int vgic_its_invall(struct kvm_vcpu *vcpu)\narch/arm64/kvm/vgic/vgic-its.c-1321-{\n"
}

gemini-3.1-pro-preview

null

null

							input: 27084
							output: 46
							thoughts: 597
						

**My Analysis of KVM ITS Fuzzing Targets**

Okay, let's break this down. My goal is to identify the best functions to target for fuzzing the KVM ITS (Interrupt Translation Service) code, specifically using syzkaller.

First, I identified a list of potential candidates: `vgic_its_invalidate_all_caches`, `vgic_its_resolve_lpi`, `vgic_its_inject_cached_translation`, `vgic_its_inject_msi`, `vgic_its_inv_lpi`, `vgic_its_invall`, and `kvm_vgic_register_its_device`. None of these directly call `vgic_its_free_collection_list`, which is a function of interest because it's called from `vgic_its_destroy`, `vgic_its_set_attr`, and `vgic_mmio_write_its_baser`. Since `vgic_its_destroy` and `vgic_its_set_attr` are part of `kvm_arm_vgic_its_ops`, and therefore reachable through KVM ioctls, these looked promising.

Initially, I was concerned about static functions being problematic because of inlining, but I recalled that syzkaller *can* resolve static functions if they're in the symbol table. I double-checked that `vgic_its_destroy` and `vgic_its_set_attr` are present in `kallsyms`. Good news! They are accessible. And, importantly, they are not inlined.

However, the ideal situation is still to prioritize non-static entrypoints if they exist.  So, I reviewed the list again looking for better options. I also explored `vgic_mmio_write_its_baser`, but that led me to `vgic_mmio_write`, which isn't defined in `vgic-its.c`.  I will need to consider that function in the future, as it is non-static.

Ultimately, I conclude that `vgic_its_set_attr` looks like a strong candidate because it's non-inlined and is directly part of the `kvm_arm_vgic_its_ops` that are triggered by syzkaller.  And if I can't find anything better, `vgic_its_destroy` will work, because it's also non-inlined and syzkaller can match its symbol. I should also check `vgic_mmio_write` in `arch/arm64/kvm/vgic/vgic-mmio.c`.

{
  "Expression": "vgic_mmio_write",
  "PathPrefix": "arch/arm64/kvm/vgic/vgic-mmio.c"
}

{
  "Output": "arch/arm64/kvm/vgic/vgic-mmio.c=25=unsigned long vgic_mmio_read_rao(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-30-\narch/arm64/kvm/vgic/vgic-mmio.c:31:void vgic_mmio_write_wi(struct kvm_vcpu *vcpu, gpa_t addr,\narch/arm64/kvm/vgic/vgic-mmio.c-32-\t\t\tunsigned int len, unsigned long val)\n--\narch/arm64/kvm/vgic/vgic-mmio.c=64=static void vgic_update_vsgi(struct vgic_irq *irq)\n--\narch/arm64/kvm/vgic/vgic-mmio.c-68-\narch/arm64/kvm/vgic/vgic-mmio.c:69:void vgic_mmio_write_group(struct kvm_vcpu *vcpu, gpa_t addr,\narch/arm64/kvm/vgic/vgic-mmio.c-70-\t\t\t   unsigned int len, unsigned long val)\n--\narch/arm64/kvm/vgic/vgic-mmio.c=96=unsigned long vgic_mmio_read_enable(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-115-\narch/arm64/kvm/vgic/vgic-mmio.c:116:void vgic_mmio_write_senable(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-117-\t\t\t     gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-164-\narch/arm64/kvm/vgic/vgic-mmio.c:165:void vgic_mmio_write_cenable(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-166-\t\t\t     gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c=304=static void __set_pending(struct kvm_vcpu *vcpu, gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-352-\narch/arm64/kvm/vgic/vgic-mmio.c:353:void vgic_mmio_write_spending(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-354-\t\t\t      gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c=389=static void __clear_pending(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-439-\narch/arm64/kvm/vgic/vgic-mmio.c:440:void vgic_mmio_write_cpending(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-441-\t\t\t      gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c=546=static void vgic_mmio_change_active(struct kvm_vcpu *vcpu, struct vgic_irq *irq,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-592-\narch/arm64/kvm/vgic/vgic-mmio.c:593:static void __vgic_mmio_write_cactive(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-594-\t\t\t\t      gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-606-\narch/arm64/kvm/vgic/vgic-mmio.c:607:void vgic_mmio_write_cactive(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-608-\t\t\t     gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-615-\narch/arm64/kvm/vgic/vgic-mmio.c:616:\t__vgic_mmio_write_cactive(vcpu, addr, len, val);\narch/arm64/kvm/vgic/vgic-mmio.c-617-\n--\narch/arm64/kvm/vgic/vgic-mmio.c=622=int vgic_mmio_uaccess_write_cactive(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-625-{\narch/arm64/kvm/vgic/vgic-mmio.c:626:\t__vgic_mmio_write_cactive(vcpu, addr, len, val);\narch/arm64/kvm/vgic/vgic-mmio.c-627-\treturn 0;\n--\narch/arm64/kvm/vgic/vgic-mmio.c-629-\narch/arm64/kvm/vgic/vgic-mmio.c:630:static void __vgic_mmio_write_sactive(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-631-\t\t\t\t      gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-643-\narch/arm64/kvm/vgic/vgic-mmio.c:644:void vgic_mmio_write_sactive(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-645-\t\t\t     gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-652-\narch/arm64/kvm/vgic/vgic-mmio.c:653:\t__vgic_mmio_write_sactive(vcpu, addr, len, val);\narch/arm64/kvm/vgic/vgic-mmio.c-654-\n--\narch/arm64/kvm/vgic/vgic-mmio.c=659=int vgic_mmio_uaccess_write_sactive(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-662-{\narch/arm64/kvm/vgic/vgic-mmio.c:663:\t__vgic_mmio_write_sactive(vcpu, addr, len, val);\narch/arm64/kvm/vgic/vgic-mmio.c-664-\treturn 0;\n--\narch/arm64/kvm/vgic/vgic-mmio.c=667=unsigned long vgic_mmio_read_priority(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-691- */\narch/arm64/kvm/vgic/vgic-mmio.c:692:void vgic_mmio_write_priority(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-693-\t\t\t      gpa_t addr, unsigned int len,\n--\narch/arm64/kvm/vgic/vgic-mmio.c=714=unsigned long vgic_mmio_read_config(struct kvm_vcpu *vcpu,\n--\narch/arm64/kvm/vgic/vgic-mmio.c-732-\narch/arm64/kvm/vgic/vgic-mmio.c:733:void vgic_mmio_write_config(struct kvm_vcpu *vcpu,\narch/arm64/kvm/vgic/vgic-mmio.c-734-\t\t\t    gpa_t addr, unsigned int len,\n"
}

gemini-3.1-pro-preview

null

null

							input: 30548
							output: 34
							thoughts: 317
						

**My Analysis of Vgic-ITS Teardown and Setup**

Okay, so I'm taking a look at the `vgic-its.c` file and trying to understand the relevant code for setup and teardown of the ITS (Interrupt Translation Service) within the KVM environment. `vgic_its_destroy` and `vgic_its_set_attr` are obviously important, but I need to make sure I haven't missed anything else critical.

Initially, I identified `kvm_vgic_register_its_device` as a non-static function that seemed like a possible point of interest. It's not *directly* involved in the execution of the changed code, it's just a registration function. So, scratch that. But, wait... after a second look, the code *actually* does something in `vgic_its_free_collection_list`.

Given that, I'm going to focus my attention on `vgic_its_destroy` and `vgic_its_set_attr` as primary points of interest because I understand these are relevant function names. Also, I need to check `vgic_its_reset`. Ah, but that one is static. Same with `vgic_its_restore_collection_table`. I will need to make sure to consider those as well, despite not using them as primary focus symbols.

Now, let's switch gears and check the Kconfig file. I see the requirement for `CONFIG_KVM` is present, which is expected. I need to make sure there aren't any other configuration dependencies. So, I will check `arch/arm64/kvm/Kconfig` for the rest of the configuration.

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

{
  "Output": "arch/arm64/kvm/Kconfig=18=if VIRTUALIZATION\narch/arm64/kvm/Kconfig-19-\narch/arm64/kvm/Kconfig:20:menuconfig KVM\narch/arm64/kvm/Kconfig-21-\tbool \"Kernel-based Virtual Machine (KVM) support\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 31364
							output: 33
							thoughts: 36
						

Okay, here's my take on those thoughts, framed as my own mental process, given my expertise:

**Checking My KVM Configuration**

Alright, so I'm focusing on the `KVM` configuration right now. It's the primary piece of this puzzle. But, hold on a minute, I need to remember that `VIRTUALIZATION` is also a critical component. They work together. So, before I go any further, I should verify dependencies. Let's see if `KVM` relies on anything specific. I'll check its dependencies, ensure nothing else is needed, and that there are no conflicts. I need a clear understanding of what `KVM` is built on.

{
  "Expression": "depends on",
  "PathPrefix": "arch/arm64/kvm/Kconfig"
}

{
  "Output": "arch/arm64/kvm/Kconfig=47=config PTDUMP_STAGE2_DEBUGFS\narch/arm64/kvm/Kconfig-48-\tbool \"Present the stage-2 pagetables to debugfs\"\narch/arm64/kvm/Kconfig:49:\tdepends on DEBUG_KERNEL\narch/arm64/kvm/Kconfig:50:\tdepends on DEBUG_FS\narch/arm64/kvm/Kconfig:51:\tdepends on ARCH_HAS_PTDUMP\narch/arm64/kvm/Kconfig-52-\tselect PTDUMP\n--\narch/arm64/kvm/Kconfig=75=config NVHE_EL2_TRACING\narch/arm64/kvm/Kconfig-76-\tbool\narch/arm64/kvm/Kconfig:77:\tdepends on TRACING \u0026\u0026 FTRACE\narch/arm64/kvm/Kconfig-78-\tselect TRACE_REMOTE\n--\narch/arm64/kvm/Kconfig=92=config PKVM_STACKTRACE\narch/arm64/kvm/Kconfig-93-\tbool \"Protected KVM hypervisor stacktraces\"\narch/arm64/kvm/Kconfig:94:\tdepends on PKVM_DISABLE_STAGE2_ON_PANIC\narch/arm64/kvm/Kconfig-95-\tdefault y\n"
}

gemini-3.1-pro-preview

null

null

							input: 31934
							output: 38
							thoughts: 30
						

Here's my take:

**Investigating the KVM Menu Configuration**

Okay, so I'm looking at this `menuconfig KVM` entry, and something feels off. There's no `depends on` clause attached to it in the snippet. That seems unusual, given KVM's dependencies on various hardware virtualization extensions and kernel features. I need to make sure I'm not missing anything crucial here. The obvious next step is to examine the *complete* definition of `KVM`. I need to understand its relationship to other configurations and precisely what conditions must be met for it to be enabled. Without that comprehensive view, I can't be confident in interpreting its place within the broader kernel configuration landscape. Let's dig deeper and get the full picture.

{
  "File": "arch/arm64/kvm/Kconfig",
  "FirstLine": 18,
  "LineCount": 30
}

{
  "Contents": "  18:\tif VIRTUALIZATION\n  19:\t\n  20:\tmenuconfig KVM\n  21:\t\tbool \"Kernel-based Virtual Machine (KVM) support\"\n  22:\t\tselect KVM_COMMON\n  23:\t\tselect KVM_GENERIC_HARDWARE_ENABLING\n  24:\t\tselect HAVE_KVM_CPU_RELAX_INTERCEPT\n  25:\t\tselect KVM_MMIO\n  26:\t\tselect KVM_GENERIC_DIRTYLOG_READ_PROTECT\n  27:\t\tselect VIRT_XFER_TO_GUEST_WORK\n  28:\t\tselect KVM_VFIO\n  29:\t\tselect HAVE_KVM_DIRTY_RING_ACQ_REL\n  30:\t\tselect NEED_KVM_DIRTY_RING_WITH_BITMAP\n  31:\t\tselect HAVE_KVM_MSI\n  32:\t\tselect HAVE_KVM_IRQCHIP\n  33:\t\tselect HAVE_KVM_IRQ_ROUTING\n  34:\t\tselect HAVE_KVM_IRQ_BYPASS\n  35:\t\tselect HAVE_KVM_READONLY_MEM\n  36:\t\tselect HAVE_KVM_VCPU_RUN_PID_CHANGE\n  37:\t\tselect SCHED_INFO\n  38:\t\tselect GUEST_PERF_EVENTS if PERF_EVENTS\n  39:\t\tselect KVM_GUEST_MEMFD\n  40:\t\thelp\n  41:\t\t  Support hosting virtualized guest machines.\n  42:\t\n  43:\t\t  If unsure, say N.\n  44:\t\n  45:\tif KVM\n  46:\t\n  47:\tconfig PTDUMP_STAGE2_DEBUGFS\n"
}

gemini-3.1-pro-preview

null

null

							input: 32596
							output: 44
							thoughts: 370
						

**My Analysis of the KVM VGIC ITS Collection Freeing Patch**

Okay, so this patch affects `KVM` and, by extension, anything using `VIRTUALIZATION`. I need to ensure both of those are included in my configuration. Let me just confirm there aren't any other obvious config dependencies... Nope, that looks clean.

Alright, let's break this down. The patch fundamentally optimizes the VGIC ITS collection freeing process within KVM on ARM64. It’s a performance improvement, switching from an O(Collections * ITEs) to O(Collections + ITEs) time complexity to mitigate RCU stalls. Critically, this change happens during guest VM teardown or ITS reset, so it's clearly relevant to those processes.

The initial analysis highlighted `vgic_its_destroy` and `vgic_its_set_attr` as primary points of interest, which makes sense given the change. However, I need to be *sure* I'm picking the right symbols. The prompt prefers non-static, non-inlined API entrypoints. These are *technically* static, but they aren't inlined, so they still provide distinct symbol addresses. Given this, I’m thinking they are still the best targets for symbolic execution.

Let's review the other possibilities, just in case. `kvm_vgic_register_its_device` doesn't seem directly relevant, as it doesn't appear to execute the modified code. `kvm_destroy_vm` is *too* generic; it could trigger *many* things. Let's not bring it in. And then there's `vgic_its_free_collection_list`, which is static, and *could* be inlined. I will stick with the original two.

So, I think I'll include `vgic_its_destroy` and `vgic_its_set_attr`. I'll just double-check that `vgic_its_destroy` isn't inlined, though.

{
  "Expression": "vgic_its_destroy",
  "PathPrefix": "arch/arm64/kvm/vgic/vgic-its.c"
}

{
  "Output": "arch/arm64/kvm/vgic/vgic-its.c=1867=static int vgic_its_create(struct kvm_device *dev, u32 type)\n--\narch/arm64/kvm/vgic/vgic-its.c-1923-\narch/arm64/kvm/vgic/vgic-its.c:1924:static void vgic_its_destroy(struct kvm_device *kvm_dev)\narch/arm64/kvm/vgic/vgic-its.c-1925-{\n--\narch/arm64/kvm/vgic/vgic-its.c=2828=static struct kvm_device_ops kvm_arm_vgic_its_ops = {\n--\narch/arm64/kvm/vgic/vgic-its.c-2830-\t.create = vgic_its_create,\narch/arm64/kvm/vgic/vgic-its.c:2831:\t.destroy = vgic_its_destroy,\narch/arm64/kvm/vgic/vgic-its.c-2832-\t.set_attr = vgic_its_set_attr,\n"
}

gemini-3.1-pro-preview

null

null

							input: 33764
							output: 50
							thoughts: 53
						

Okay, here's my interpretation of those thoughts, presented as my own mental process:

**Diving into this Function Call**

Alright, I see this function being passed around as a function pointer, which means, by definition, it's *not* going to get inlined. Same goes for `vgic_its_set_attr`, then. Just a quick sanity check to be sure, I should jump over to `vgic_mmio_write_its_baser`. Need to quickly review that one.

{
  "Expression": "vgic_mmio_write_its_baser",
  "PathPrefix": "arch/arm64/kvm/vgic/vgic-its.c"
}

{
  "Output": "arch/arm64/kvm/vgic/vgic-its.c=1645=static unsigned long vgic_mmio_read_its_baser(struct kvm *kvm,\n--\narch/arm64/kvm/vgic/vgic-its.c-1666-#define GITS_BASER_RO_MASK\t(GENMASK_ULL(52, 48) | GENMASK_ULL(58, 56))\narch/arm64/kvm/vgic/vgic-its.c:1667:static void vgic_mmio_write_its_baser(struct kvm *kvm,\narch/arm64/kvm/vgic/vgic-its.c-1668-\t\t\t\t      struct vgic_its *its,\n--\narch/arm64/kvm/vgic/vgic-its.c=1792=static struct vgic_register_region its_registers[] = {\n--\narch/arm64/kvm/vgic/vgic-its.c-1813-\tREGISTER_ITS_DESC(GITS_BASER,\narch/arm64/kvm/vgic/vgic-its.c:1814:\t\tvgic_mmio_read_its_baser, vgic_mmio_write_its_baser, 0x40,\narch/arm64/kvm/vgic/vgic-its.c-1815-\t\tVGIC_ACCESS_64bit | VGIC_ACCESS_32bit),\n"
}

gemini-3.1-pro-preview

null

null

							input: 34367
							output: 150
							thoughts: 112
						

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

**Analyzing ITS Function Pointers and Potential Weaknesses**

Right, so I'm looking at the `REGISTER_ITS_DESC` macro. And it's passing a function pointer. That means the function isn't being inlined, which is something I need to keep in mind for performance analysis. It means I need to also add `vgic_mmio_write_its_baser` to my list of focus symbols. It directly calls `vgic_its_free_collection_list`, which is a key function to examine for memory management and potential issues, which is something I need to keep in mind, and expand my analysis too.

Therefore, for this particular analysis, I will add `vgic_its_destroy`, `vgic_its_set_attr` and `vgic_mmio_write_its_baser` to my FocusSymbols list.

Now, let's go ahead and call `set-results`.

{
  "EnableConfigs": [
    "KVM",
    "VIRTUALIZATION"
  ],
  "FocusSymbols": [
    "vgic_its_destroy",
    "vgic_its_set_attr",
    "vgic_mmio_write_its_baser"
  ],
  "Reasoning": "The patch optimizes the teardown of KVM VGIC ITS collections by changing the complexity from O(Collections * ITEs) to O(Collections + ITEs) to prevent host RCU stalls. This is a functional change in the ARM64 KVM architecture code that is reachable during guest VM teardown or ITS reset, making it worth fuzzing.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "KVM",
    "VIRTUALIZATION"
  ],
  "FocusSymbols": [
    "vgic_its_destroy",
    "vgic_its_set_attr",
    "vgic_mmio_write_its_baser"
  ],
  "Reasoning": "The patch optimizes the teardown of KVM VGIC ITS collections by changing the complexity from O(Collections * ITEs) to O(Collections + ITEs) to prevent host RCU stalls. This is a functional change in the ARM64 KVM architecture code that is reachable during guest VM teardown or ITS reset, making it worth fuzzing.",
  "WorthFuzzing": true
}

{
  "WorthFuzzing": true
}

null

best-expensive

null

{
  "KMSANReasoning": "The patch optimizes the teardown of ITS collections by bulk-clearing the collection pointers for all ITEs before freeing the collections, reducing the time complexity from O(Collections * ITEs) to O(Collections + ITEs) to prevent guest-triggered host RCU stalls. The changes only involve pointer assignments (`ite-\u003ecollection = NULL`) and memory deallocation (`kfree`). There are no new memory allocations, no data copied to user space, and no conditional logic depending on potentially uninitialized memory. Any bugs introduced by this change (e.g., use-after-free, NULL pointer dereference) would be reliably detected by KASAN. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false
}

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.

For your convenience, here is the diff of the changes:
commit 2d8ee5452bbbc7fa39f9001c9b1781d8007fe659
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Aug 18 23:17:41 2026 +0000

    syz-cluster: applied patch under review

diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
index 36ab3e4929154..a8e819fe97898 100644
--- a/arch/arm64/kvm/vgic/vgic-its.c
+++ b/arch/arm64/kvm/vgic/vgic-its.c
@@ -1133,9 +1133,21 @@ static void vgic_its_free_device_list(struct kvm *kvm, struct vgic_its *its)
 static void vgic_its_free_collection_list(struct kvm *kvm, struct vgic_its *its)
 {
 	struct its_collection *cur, *temp;
+	struct its_device *device;
+	struct its_ite *ite;
 
-	list_for_each_entry_safe(cur, temp, &its->collection_list, coll_list)
-		vgic_its_free_collection(its, cur->collection_id);
+	/*
+	 * Bulk-clear the collection pointers for all ITEs.
+	 * This transforms the teardown complexity from O(Collections * ITEs)
+	 * to O(Collections + ITEs), avoiding guest-triggered host RCU stalls.
+	 */
+	for_each_lpi_its(device, ite, its)
+		ite->collection = NULL;
+
+	list_for_each_entry_safe(cur, temp, &its->collection_list, coll_list) {
+		list_del(&cur->coll_list);
+		kfree(cur);
+	}
 }
 
 /* Must be called with its_lock mutex held */

gemini-3.1-pro-preview

null

null

							input: 2224
							output: 46
							thoughts: 486
						

**Analyzing the Vgic ITS Teardown Optimization**

Okay, so this patch is aimed squarely at optimizing the teardown process of the Virtual Generic Interrupt Controller's (VGIC) Interrupt Translation Service (ITS) implementation, specifically in the `vgic_its_free_collection_list` function. The original implementation, which iterated through both collections and interrupt translation entries (ITEs), resulted in a teardown complexity that was O(Collections * ITEs). That's a nasty scaling factor. This could lead to guest-triggered RCU (Read-Copy Update) stalls, which are the bane of any real-time system.

My first thought is, "good riddance!" This is a classic example of where you *absolutely* want to improve the time complexity. Instead of iterating, the patch introduces a pre-pass: we bulk-clear the collection pointers for all ITEs before we actually free the collections themselves. The new complexity becomes O(Collections + ITEs). Much better. It appears that it does so by iterating through the ITEs, setting `ite->collection = NULL` directly. Then it can safely free all collections.

My next step is to quickly rule out any obvious security concerns. Is there any risk of an uninitialized memory read or information leak? Let's see: the patch just sets the `ite->collection` pointers to NULL and then frees the memory. There's no new memory allocation, no copying data to user space that could expose internal structures, and no conditional logic that depends on uninitialized data. The core of the patch is about pointer manipulation and memory deallocation to fix an RCU stall. If there *is* a bug introduced here, it's likely a use-after-free or a null pointer dereference which KASAN (Kernel Address Sanitizer) is designed to catch.

Given this, I can confidently state that KMSAN (Kernel Memory Sanitizer) isn't necessary here. This change doesn't introduce any obvious uninitialized memory reads or information leaks. I might quickly glance at `vgic_its_free_collection` just to confirm my understanding of the pre-optimization code, but I'm feeling good about this change. It's a clean, targeted optimization that should address a real performance bottleneck.

{
  "Expression": "vgic_its_free_collection",
  "PathPrefix": "arch/arm64/kvm/vgic/vgic-its.c"
}

{
  "Output": "arch/arm64/kvm/vgic/vgic-its.c=971=static int vgic_its_alloc_collection(struct vgic_its *its,\n--\narch/arm64/kvm/vgic/vgic-its.c-989-\narch/arm64/kvm/vgic/vgic-its.c:990:static void vgic_its_free_collection(struct vgic_its *its, u32 coll_id)\narch/arm64/kvm/vgic/vgic-its.c-991-{\n--\narch/arm64/kvm/vgic/vgic-its.c=1036=static int vgic_its_cmd_handle_mapi(struct kvm *kvm, struct vgic_its *its,\n--\narch/arm64/kvm/vgic/vgic-its.c-1083-\t\tif (new_coll)\narch/arm64/kvm/vgic/vgic-its.c:1084:\t\t\tvgic_its_free_collection(its, coll_id);\narch/arm64/kvm/vgic/vgic-its.c-1085-\t\treturn PTR_ERR(ite);\n--\narch/arm64/kvm/vgic/vgic-its.c-1093-\t\tif (new_coll)\narch/arm64/kvm/vgic/vgic-its.c:1094:\t\t\tvgic_its_free_collection(its, coll_id);\narch/arm64/kvm/vgic/vgic-its.c-1095-\t\tits_free_ite(kvm, ite);\n--\narch/arm64/kvm/vgic/vgic-its.c=1124=static void vgic_its_free_device_list(struct kvm *kvm, struct vgic_its *its)\n--\narch/arm64/kvm/vgic/vgic-its.c-1132-/* its lock must be held */\narch/arm64/kvm/vgic/vgic-its.c:1133:static void vgic_its_free_collection_list(struct kvm *kvm, struct vgic_its *its)\narch/arm64/kvm/vgic/vgic-its.c-1134-{\n--\narch/arm64/kvm/vgic/vgic-its.c=1220=static int vgic_its_cmd_handle_mapc(struct kvm *kvm, struct vgic_its *its,\n--\narch/arm64/kvm/vgic/vgic-its.c-1230-\tif (!valid) {\narch/arm64/kvm/vgic/vgic-its.c:1231:\t\tvgic_its_free_collection(its, coll_id);\narch/arm64/kvm/vgic/vgic-its.c-1232-\t\tvgic_its_invalidate_cache(its);\n--\narch/arm64/kvm/vgic/vgic-its.c=1667=static void vgic_mmio_write_its_baser(struct kvm *kvm,\n--\narch/arm64/kvm/vgic/vgic-its.c-1713-\t\tcase GITS_BASER_TYPE_COLLECTION:\narch/arm64/kvm/vgic/vgic-its.c:1714:\t\t\tvgic_its_free_collection_list(kvm, its);\narch/arm64/kvm/vgic/vgic-its.c-1715-\t\t\tbreak;\n--\narch/arm64/kvm/vgic/vgic-its.c=1924=static void vgic_its_destroy(struct kvm_device *kvm_dev)\n--\narch/arm64/kvm/vgic/vgic-its.c-1933-\tvgic_its_free_device_list(kvm, its);\narch/arm64/kvm/vgic/vgic-its.c:1934:\tvgic_its_free_collection_list(kvm, its);\narch/arm64/kvm/vgic/vgic-its.c-1935-\tvgic_its_invalidate_cache(its);\n--\narch/arm64/kvm/vgic/vgic-its.c=2569=static int vgic_its_restore_collection_table(struct vgic_its *its)\n--\narch/arm64/kvm/vgic/vgic-its.c-2596-\tif (ret \u003c 0)\narch/arm64/kvm/vgic/vgic-its.c:2597:\t\tvgic_its_free_collection_list(its-\u003edev-\u003ekvm, its);\narch/arm64/kvm/vgic/vgic-its.c-2598-\n--\narch/arm64/kvm/vgic/vgic-its.c=2622=static int vgic_its_restore_tables_v0(struct vgic_its *its)\n--\narch/arm64/kvm/vgic/vgic-its.c-2631-\tif (ret)\narch/arm64/kvm/vgic/vgic-its.c:2632:\t\tvgic_its_free_collection_list(its-\u003edev-\u003ekvm, its);\narch/arm64/kvm/vgic/vgic-its.c-2633-\treturn ret;\n--\narch/arm64/kvm/vgic/vgic-its.c=2651=static void vgic_its_reset(struct kvm *kvm, struct vgic_its *its)\n--\narch/arm64/kvm/vgic/vgic-its.c-2660-\tvgic_its_free_device_list(kvm, its);\narch/arm64/kvm/vgic/vgic-its.c:2661:\tvgic_its_free_collection_list(kvm, its);\narch/arm64/kvm/vgic/vgic-its.c-2662-}\n"
}

gemini-3.1-pro-preview

null

null

							input: 4799
							output: 175
							thoughts: 149
						

**My Assessment of the Vgic ITS Freeing Optimization**

Okay, so I'm looking at this patch and my initial thought is, "smart move." They've recognized that the original `vgic_its_free_collection_list` was potentially causing performance bottlenecks, specifically with that O(Collections * ITEs) teardown complexity. That's a classic recipe for RCU stalls, and we know those are a real pain to debug.

What they've done, bulk-clearing those collection pointers before freeing the collections directly, is a clever optimization. It avoids the per-collection loop, which is exactly the right approach to minimize the impact. Efficiency is key here.

Now, I'm analyzing it for potential issues. The good news is, there's nothing immediately screaming "security vulnerability." No new memory allocation, no chance of uninitialized memory making its way to userspace. The potential problems here are textbook memory safety issues: use-after-free, double frees, or null pointer dereferences. But those are the bread and butter of KASAN's detection capabilities. That's precisely what it's there for. So, while I'll still give it a thorough once-over, I'm confident that KMSAN isn't going to be needed for this particular change. KASAN should be more than sufficient.

{
  "KMSANReasoning": "The patch optimizes the teardown of ITS collections by bulk-clearing the collection pointers for all ITEs before freeing the collections, reducing the time complexity from O(Collections * ITEs) to O(Collections + ITEs) to prevent guest-triggered host RCU stalls. The changes only involve pointer assignments (`ite-\u003ecollection = NULL`) and memory deallocation (`kfree`). There are no new memory allocations, no data copied to user space, and no conditional logic depending on potentially uninitialized memory. Any bugs introduced by this change (e.g., use-after-free, NULL pointer dereference) would be reliably detected by KASAN. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false
}

{
  "KMSANReasoning": "The patch optimizes the teardown of ITS collections by bulk-clearing the collection pointers for all ITEs before freeing the collections, reducing the time complexity from O(Collections * ITEs) to O(Collections + ITEs) to prevent guest-triggered host RCU stalls. The changes only involve pointer assignments (`ite-\u003ecollection = NULL`) and memory deallocation (`kfree`). There are no new memory allocations, no data copied to user space, and no conditional logic depending on potentially uninitialized memory. Any bugs introduced by this change (e.g., use-after-free, NULL pointer dereference) would be reliably detected by KASAN. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false
}