AI Trajectory

Trajectory: (Expand/Collapse All)
Seq	Timestamp	Type	Name	Duration
0/0	2026/08/06 21:14	flow	patch-triage	3m Args: null Results: { "EnableConfigs": null, "FocusSymbols": [ "vfio_ap_mdev_open_device", "vfio_ap_mdev_close_device", "vfio_ap_mdev_set_kvm", "vfio_ap_mdev_unset_kvm" ], "Reasoning": "The patch modifies locking semantics and state management in the VFIO AP driver when a mediated device is attached to or detached from a KVM guest. The vfio_ap driver can be loaded and mdevs can be created and opened in a virtualized environment without requiring physical AP hardware, making this code reachable and fuzzable via sysfs and VFIO ioctls. (Note: VFIO_AP config is required but omitted from EnableConfigs as it is s390x specific and rejected by the tool).", "WorthFuzzing": true }
1/1	2026/08/06 21:14	action	read-patch-diff	0m Args: null Results: { "PatchDiff": "commit efbff8dc4ed7661b87ee85af321ec33acc49a025\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Thu Aug 6 21:14:32 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c\nindex 44b3a1dcc1b36..99a0efd999ef9 100644\n--- a/drivers/s390/crypto/vfio_ap_ops.c\n+++ b/drivers/s390/crypto/vfio_ap_ops.c\n@@ -48,15 +48,19 @@ static void vfio_ap_mdev_reset_queue(struct vfio_ap_queue q);\n 1. matrix_dev-\u003eguests_lock: required to use the KVM pointer to update a KVM\n \t\t\t guest's APCB.\n 2. kvm-\u003elock:\t required to update a guest's APCB\n- * 3. matrix_dev-\u003emdevs_lock: required to access data stored in a matrix_mdev\n+ * 3. kvm-\u003earch.crypto.pqap_hook_rwsem: required to update pqap_hook and\n+ \t\t\t\t\tserialize against PQAP intercepts\n+ 4. matrix_dev-\u003emdevs_lock: required to access data stored in a matrix_mdev\n \n- Note: If @kvm is NULL, the KVM lock will not be taken.\n+ * Note: If @kvm is NULL, the KVM lock and pqap_hook_rwsem will not be taken.\n /\n static inline void get_update_locks_for_kvm(struct kvm kvm)\n {\n \tmutex_lock(\u0026matrix_dev-\u003eguests_lock);\n-\tif (kvm)\n+\tif (kvm) {\n \t\tmutex_lock(\u0026kvm-\u003elock);\n+\t\tdown_write(\u0026kvm-\u003earch.crypto.pqap_hook_rwsem);\n+\t}\n \tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\n }\n \n@@ -68,16 +72,19 @@ static inline void get_update_locks_for_kvm(struct kvm kvm)\n \n * The proper unlocking order is:\n * 1. matrix_dev-\u003emdevs_lock\n- * 2. kvm-\u003elock\n- * 3. matrix_dev-\u003eguests_lock\n+ * 2. kvm-\u003earch.crypto.pqap_hook_rwsem\n+ * 3. kvm-\u003elock\n+ * 4. matrix_dev-\u003eguests_lock\n \n- Note: If @kvm is NULL, the KVM lock will not be released.\n+ * Note: If @kvm is NULL, the KVM lock and pqap_hook_rwsem will not be released.\n /\n static inline void release_update_locks_for_kvm(struct kvm kvm)\n {\n \tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\n-\tif (kvm)\n+\tif (kvm) {\n+\t\tup_write(\u0026kvm-\u003earch.crypto.pqap_hook_rwsem);\n \t\tmutex_unlock(\u0026kvm-\u003elock);\n+\t}\n \tmutex_unlock(\u0026matrix_dev-\u003eguests_lock);\n }\n \n@@ -1821,26 +1828,17 @@ static const struct attribute_group vfio_ap_mdev_attr_groups[] = {\n static int vfio_ap_mdev_set_kvm(struct ap_matrix_mdev matrix_mdev,\n \t\t\t\tstruct kvm kvm)\n {\n-\tstruct ap_matrix_mdev m;\n-\n \tif (kvm-\u003earch.crypto.crycbd) {\n-\t\tdown_write(\u0026kvm-\u003earch.crypto.pqap_hook_rwsem);\n-\t\tkvm-\u003earch.crypto.pqap_hook = \u0026matrix_mdev-\u003epqap_hook;\n-\t\tup_write(\u0026kvm-\u003earch.crypto.pqap_hook_rwsem);\n-\n \t\tget_update_locks_for_kvm(kvm);\n-\n-\t\tlist_for_each_entry(m, \u0026matrix_dev-\u003emdev_list, node) {\n-\t\t\tif (m != matrix_mdev \u0026\u0026 m-\u003ekvm == kvm) {\n-\t\t\t\trelease_update_locks_for_kvm(kvm);\n-\t\t\t\treturn -EPERM;\n-\t\t\t}\n+\t\tif (kvm-\u003earch.crypto.pqap_hook) {\n+\t\t\trelease_update_locks_for_kvm(kvm);\n+\t\t\treturn -EPERM;\n \t\t}\n+\t\tkvm-\u003earch.crypto.pqap_hook = \u0026matrix_mdev-\u003epqap_hook;\n \n \t\tkvm_get_kvm(kvm);\n \t\tmatrix_mdev-\u003ekvm = kvm;\n \t\tvfio_ap_mdev_update_guest_apcb(matrix_mdev);\n-\n \t\trelease_update_locks_for_kvm(kvm);\n \t}\n \n@@ -1883,18 +1881,15 @@ static void vfio_ap_mdev_unset_kvm(struct ap_matrix_mdev matrix_mdev)\n \tstruct kvm kvm = matrix_mdev-\u003ekvm;\n \n \tif (kvm \u0026\u0026 kvm-\u003earch.crypto.crycbd) {\n-\t\tdown_write(\u0026kvm-\u003earch.crypto.pqap_hook_rwsem);\n-\t\tkvm-\u003earch.crypto.pqap_hook = NULL;\n-\t\tup_write(\u0026kvm-\u003earch.crypto.pqap_hook_rwsem);\n-\n \t\tget_update_locks_for_kvm(kvm);\n+\t\tkvm-\u003earch.crypto.pqap_hook = NULL;\n \n \t\tkvm_arch_crypto_clear_masks(kvm);\n \t\tvfio_ap_mdev_reset_queues(matrix_mdev);\n-\t\tkvm_put_kvm(kvm);\n \t\tmatrix_mdev-\u003ekvm = NULL;\n \n \t\trelease_update_locks_for_kvm(kvm);\n+\t\tkvm_put_kvm(kvm);\n \t}\n }\n \n" }
2/1	2026/08/06 21:14	agent	patch-evaluator	3m Model: best-expensive Args: null Results: { "EnableConfigs": null, "FocusSymbols": [ "vfio_ap_mdev_open_device", "vfio_ap_mdev_close_device", "vfio_ap_mdev_set_kvm", "vfio_ap_mdev_unset_kvm" ], "Reasoning": "The patch modifies locking semantics and state management in the VFIO AP driver when a mediated device is attached to or detached from a KVM guest. The vfio_ap driver can be loaded and mdevs can be created and opened in a virtualized environment without requiring physical AP hardware, making this code reachable and fuzzable via sysfs and VFIO ioctls. (Note: VFIO_AP config is required but omitted from EnableConfigs as it is s390x specific and rejected by the tool).", "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). - 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. Prompt: For your convenience, here is the diff of the changes: commit efbff8dc4ed7661b87ee85af321ec33acc49a025 Author: syz-cluster <triage@syzkaller.com> Date: Thu Aug 6 21:14:32 2026 +0000 syz-cluster: applied patch under review diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c index 44b3a1dcc1b36..99a0efd999ef9 100644 --- a/drivers/s390/crypto/vfio_ap_ops.c +++ b/drivers/s390/crypto/vfio_ap_ops.c @@ -48,15 +48,19 @@ static void vfio_ap_mdev_reset_queue(struct vfio_ap_queue q); 1. matrix_dev->guests_lock: required to use the KVM pointer to update a KVM * guest's APCB. * 2. kvm->lock: required to update a guest's APCB - * 3. matrix_dev->mdevs_lock: required to access data stored in a matrix_mdev + * 3. kvm->arch.crypto.pqap_hook_rwsem: required to update pqap_hook and + * serialize against PQAP intercepts + * 4. matrix_dev->mdevs_lock: required to access data stored in a matrix_mdev * - * Note: If @kvm is NULL, the KVM lock will not be taken. + * Note: If @kvm is NULL, the KVM lock and pqap_hook_rwsem will not be taken. / static inline void get_update_locks_for_kvm(struct kvm kvm) { mutex_lock(&matrix_dev->guests_lock); - if (kvm) + if (kvm) { mutex_lock(&kvm->lock); + down_write(&kvm->arch.crypto.pqap_hook_rwsem); + } mutex_lock(&matrix_dev->mdevs_lock); } @@ -68,16 +72,19 @@ static inline void get_update_locks_for_kvm(struct kvm kvm) * The proper unlocking order is: * 1. matrix_dev->mdevs_lock - * 2. kvm->lock - * 3. matrix_dev->guests_lock + * 2. kvm->arch.crypto.pqap_hook_rwsem + * 3. kvm->lock + * 4. matrix_dev->guests_lock * - * Note: If @kvm is NULL, the KVM lock will not be released. + * Note: If @kvm is NULL, the KVM lock and pqap_hook_rwsem will not be released. / static inline void release_update_locks_for_kvm(struct kvm kvm) { mutex_unlock(&matrix_dev->mdevs_lock); - if (kvm) + if (kvm) { + up_write(&kvm->arch.crypto.pqap_hook_rwsem); mutex_unlock(&kvm->lock); + } mutex_unlock(&matrix_dev->guests_lock); } @@ -1821,26 +1828,17 @@ static const struct attribute_group vfio_ap_mdev_attr_groups[] = { static int vfio_ap_mdev_set_kvm(struct ap_matrix_mdev matrix_mdev, struct kvm kvm) { - struct ap_matrix_mdev m; - if (kvm->arch.crypto.crycbd) { - down_write(&kvm->arch.crypto.pqap_hook_rwsem); - kvm->arch.crypto.pqap_hook = &matrix_mdev->pqap_hook; - up_write(&kvm->arch.crypto.pqap_hook_rwsem); - get_update_locks_for_kvm(kvm); - - list_for_each_entry(m, &matrix_dev->mdev_list, node) { - if (m != matrix_mdev && m->kvm == kvm) { - release_update_locks_for_kvm(kvm); - return -EPERM; - } + if (kvm->arch.crypto.pqap_hook) { + release_update_locks_for_kvm(kvm); + return -EPERM; } + kvm->arch.crypto.pqap_hook = &matrix_mdev->pqap_hook; kvm_get_kvm(kvm); matrix_mdev->kvm = kvm; vfio_ap_mdev_update_guest_apcb(matrix_mdev); - release_update_locks_for_kvm(kvm); } @@ -1883,18 +1881,15 @@ static void vfio_ap_mdev_unset_kvm(struct ap_matrix_mdev matrix_mdev) struct kvm kvm = matrix_mdev->kvm; if (kvm && kvm->arch.crypto.crycbd) { - down_write(&kvm->arch.crypto.pqap_hook_rwsem); - kvm->arch.crypto.pqap_hook = NULL; - up_write(&kvm->arch.crypto.pqap_hook_rwsem); - get_update_locks_for_kvm(kvm); + kvm->arch.crypto.pqap_hook = NULL; kvm_arch_crypto_clear_masks(kvm); vfio_ap_mdev_reset_queues(matrix_mdev); - kvm_put_kvm(kvm); matrix_mdev->kvm = NULL; release_update_locks_for_kvm(kvm); + kvm_put_kvm(kvm); } }
3/2	2026/08/06 21:14	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 3342 output: 26 thoughts: 474 Thoughts: VFIO AP Locking Changes - Worth Fuzzing? Okay, so I'm looking at this patch for `drivers/s390/crypto/vfio_ap_ops.c`. It's pretty straightforward: they're adding write locks (`down_write`, `up_write`) around the `kvm->arch.crypto.pqap_hook_rwsem` semaphore in `get_update_locks_for_kvm`, `release_update_locks_for_kvm`, `vfio_ap_mdev_set_kvm` and `vfio_ap_mdev_unset_kvm`. It's all about synchronizing access to `kvm->arch.crypto.pqap_hook`, which makes sense. Right, so this is VFIO AP on s390x. I know this code, it's about passing through cryptographic hardware to KVM guests. And because it's s390-specific and relies on physical AP cards, my initial gut feeling is that it's going to be a pain to fuzz. Standard QEMU doesn't really emulate this stuff, does it? It's not like a generic PCIe device. I'd need actual AP hardware, and VFIO pass-through of specific devices. But, hang on, syzkaller does support s390x, which is encouraging. The question is whether it supports VFIO AP. I need to figure out if there's any support or definitions for VFIO AP within syzkaller's framework. Let me check the documentation. Okay, let's see, what does the prompt say? This prompt says to return `WorthFuzzing=false` if the code path is unreachable in standard QEMU. VFIO AP requires physical AP cards. So that is the relevant information. QEMU does emulate a lot of stuff, but it's specifically for passing through physical AP cards to guests. So, in conclusion, based on my understanding, this is probably not worth fuzzing unless syzkaller has some specific, and probably very advanced, support for emulating or simulating AP card pass-through. Without that, it's just not going to happen in a standard fuzzing setup. I need to look into syzkaller's VFIO AP capabilities.
4/2	2026/08/06 21:14	tool	grepper	0m Args: { "Expression": "vfio_ap_mdev_set_kvm" } Results: { "Output": "drivers/s390/crypto/vfio_ap_ops.c=1813=static const struct attribute_group vfio_ap_mdev_attr_groups[] = {\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1818-/\ndrivers/s390/crypto/vfio_ap_ops.c:1819: vfio_ap_mdev_set_kvm - sets all data for @matrix_mdev that are needed\ndrivers/s390/crypto/vfio_ap_ops.c-1820- * to manage AP resources for the guest whose state is represented by @kvm\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1827- /\ndrivers/s390/crypto/vfio_ap_ops.c:1828:static int vfio_ap_mdev_set_kvm(struct ap_matrix_mdev matrix_mdev,\ndrivers/s390/crypto/vfio_ap_ops.c-1829-\t\t\t\tstruct kvm kvm)\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2048=static int vfio_ap_mdev_open_device(struct vfio_device vdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2055-\ndrivers/s390/crypto/vfio_ap_ops.c:2056:\treturn vfio_ap_mdev_set_kvm(matrix_mdev, vdev-\u003ekvm);\ndrivers/s390/crypto/vfio_ap_ops.c-2057-}\n" }
5/2	2026/08/06 21:14	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 4782 output: 25 thoughts: 143 Thoughts: My Initial Thoughts on VFIO AP MDev Okay, so `vfio_ap_mdev_set_kvm` is called from `vfio_ap_mdev_open_device`. Makes sense, but I need to make sure I understand the call chain. Is `vfio_ap_mdev_open_device` the entry point? Yes, it's a VFIO device open callback. Right, so VFIO AP is dealing with mediated devices here, the mdev driver. Now the real question pops up: can we actually get this working in a virtualized environment without any physical AP hardware? I need to dig into the code to figure this out, specifically `drivers/s390/crypto/vfio_ap_drv.c` and `drivers/s390/crypto/vfio_ap_ops.c`. That's where the heart of this should be.
6/2	2026/08/06 21:14	tool	grepper	0m Args: { "Expression": "vfio_ap_mdev_open_device" } Results: { "Output": "drivers/s390/crypto/vfio_ap_ops.c=2030=static int vfio_ap_mdev_reset_qlist(struct list_head qlist)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2047-\ndrivers/s390/crypto/vfio_ap_ops.c:2048:static int vfio_ap_mdev_open_device(struct vfio_device vdev)\ndrivers/s390/crypto/vfio_ap_ops.c-2049-{\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2356=static const struct vfio_device_ops vfio_ap_matrix_dev_ops = {\ndrivers/s390/crypto/vfio_ap_ops.c-2357-\t.init = vfio_ap_mdev_init_dev,\ndrivers/s390/crypto/vfio_ap_ops.c:2358:\t.open_device = vfio_ap_mdev_open_device,\ndrivers/s390/crypto/vfio_ap_ops.c-2359-\t.close_device = vfio_ap_mdev_close_device,\n" }
7/2	2026/08/06 21:14	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 5475 output: 22 thoughts: 57 Thoughts: Okay, here's my take on those thoughts, framed as my own mental processing as an expert in VFIO and AP devices: VFIO AP mdev Creation Deep Dive Alright, so I'm thinking about setting up a VFIO AP mediated device, or mdev. First things first: `vfio_ap` module needs to be loaded. That's fundamental. Then, I need to make sure the matrix device is present. I'm pretty certain that the matrix device is the key enabler here. Now, where is that matrix device instantiated? Right, it's created within `vfio_ap_drv.c`. Okay, good. Let's dig into that source file and see exactly how it's brought into existence. Understanding its creation process will be crucial for any troubleshooting or advanced configurations I might need to perform down the line. It's the lynchpin, so I need a solid understanding of this part. Time to open that file.
8/2	2026/08/06 21:14	tool	grepper	0m Error: no matches Args: { "Expression": "ap_matrix_mdev_create" } Results: { "error": "no matches" }
9/2	2026/08/06 21:14	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 5776 output: 17 thoughts: 29 Thoughts: Okay, let's dive into this. Here's my thought process on what we're looking at, summarized from that prompt: Investigating `vfio_ap_drv.c` for `matrix_dev` Alright, I need to get my bearings. Let's start by zeroing in on `drivers/s390/crypto/vfio_ap_drv.c`. The core question is always how something like `matrix_dev` is used. I'm going to scan the code for that variable, see how it's defined, initialized, and, crucially, how it interacts with other components of this driver. I'm especially interested in any data structures related to the hardware or the VFIO interface. I expect to be able to understand the basic control flow through this. I will look for how this driver handles the AP device and communicates with the system. I need to understand how the `matrix_dev` fits into the broader picture of VFIO, especially as it relates to cryptographic acceleration on s390 systems. I will also be on the lookout for potential areas for optimization, or points that could be improved in terms of clarity or error handling, given my familiarity with the architecture and cryptographic primitives.
10/2	2026/08/06 21:14	tool	grepper	0m Args: { "Expression": "matrix_dev" } Results: { "Output": "Documentation/arch/s390/vfio-ap-locking.rst=8=will be used to denote instances of the structures herein described:\n--\nDocumentation/arch/s390/vfio-ap-locking.rst-11-\nDocumentation/arch/s390/vfio-ap-locking.rst:12: struct ap_matrix_dev matrix_dev;\nDocumentation/arch/s390/vfio-ap-locking.rst-13- struct ap_matrix_mdev matrix_mdev;\n--\nDocumentation/arch/s390/vfio-ap-locking.rst=16=The Matrix Devices Lock (drivers/s390/crypto/vfio_ap_private.h)\n--\nDocumentation/arch/s390/vfio-ap-locking.rst-20-\nDocumentation/arch/s390/vfio-ap-locking.rst:21: struct ap_matrix_dev {\nDocumentation/arch/s390/vfio-ap-locking.rst-22- \t...\n--\nDocumentation/arch/s390/vfio-ap-locking.rst-27-\nDocumentation/arch/s390/vfio-ap-locking.rst:28:The Matrix Devices Lock (matrix_dev-\u003emdevs_lock) is implemented as a global\nDocumentation/arch/s390/vfio-ap-locking.rst:29:mutex contained within the single object of struct ap_matrix_dev. This lock\nDocumentation/arch/s390/vfio-ap-locking.rst-30-controls access to all fields contained within each matrix_mdev\nDocumentation/arch/s390/vfio-ap-locking.rst:31:(matrix_dev-\u003emdev_list). This lock must be held while reading from, writing to\nDocumentation/arch/s390/vfio-ap-locking.rst-32-or using the data from a field contained within a matrix_mdev instance\n--\nDocumentation/arch/s390/vfio-ap-locking.rst=54=The Guests Lock (drivers/s390/crypto/vfio_ap_private.h)\n--\nDocumentation/arch/s390/vfio-ap-locking.rst-58-\nDocumentation/arch/s390/vfio-ap-locking.rst:59: struct ap_matrix_dev {\nDocumentation/arch/s390/vfio-ap-locking.rst-60- \t...\n--\nDocumentation/arch/s390/vfio-ap-locking.rst-65-\nDocumentation/arch/s390/vfio-ap-locking.rst:66:The Guests Lock (matrix_dev-\u003eguests_lock) controls access to the\nDocumentation/arch/s390/vfio-ap-locking.rst:67:matrix_mdev instances (matrix_dev-\u003emdev_list) that represent mediated devices\nDocumentation/arch/s390/vfio-ap-locking.rst-68-that hold the state for the mediated devices that have been attached to a\nDocumentation/arch/s390/vfio-ap-locking.rst=69=KVM guest. This lock must be held:\n--\nDocumentation/arch/s390/vfio-ap-locking.rst-74-\nDocumentation/arch/s390/vfio-ap-locking.rst:75:2. To add matrix_mdev instances to or remove them from matrix_dev-\u003emdev_list.\nDocumentation/arch/s390/vfio-ap-locking.rst-76- This is necessary to ensure the proper locking order when the list is perused\n--\nDocumentation/arch/s390/vfio-ap-locking.rst=89=pointer is not used to plug/unplug devices passed through to the KVM guest;\nDocumentation/arch/s390/vfio-ap-locking.rst:90:however, in this case, the Matrix Devices Lock (matrix_dev-\u003emdevs_lock) must be\nDocumentation/arch/s390/vfio-ap-locking.rst-91-held in order to access the KVM pointer since it is set and cleared under the\n--\nDocumentation/arch/s390/vfio-ap-locking.rst=94=needs to access the KVM pointer only for the purposes of setting or clearing IRQ\nDocumentation/arch/s390/vfio-ap-locking.rst:95:resources, so only the matrix_dev-\u003emdevs_lock needs to be held.\nDocumentation/arch/s390/vfio-ap-locking.rst-96-\n--\ndrivers/s390/crypto/vfio_ap_drv.c=24=MODULE_LICENSE(\"GPL v2\");\ndrivers/s390/crypto/vfio_ap_drv.c-25-\ndrivers/s390/crypto/vfio_ap_drv.c:26:struct ap_matrix_dev matrix_dev;\ndrivers/s390/crypto/vfio_ap_drv.c-27-debug_info_t vfio_ap_dbf_info;\n--\ndrivers/s390/crypto/vfio_ap_drv.c=33=static DEVICE_ATTR_RO(features);\ndrivers/s390/crypto/vfio_ap_drv.c-34-\ndrivers/s390/crypto/vfio_ap_drv.c:35:static struct attribute matrix_dev_attrs[] = {\ndrivers/s390/crypto/vfio_ap_drv.c-36-\t\u0026dev_attr_features.attr,\n--\ndrivers/s390/crypto/vfio_ap_drv.c-38-};\ndrivers/s390/crypto/vfio_ap_drv.c:39:ATTRIBUTE_GROUPS(matrix_dev);\ndrivers/s390/crypto/vfio_ap_drv.c-40-\n--\ndrivers/s390/crypto/vfio_ap_drv.c=58=static struct ap_driver vfio_ap_drv = {\n--\ndrivers/s390/crypto/vfio_ap_drv.c-66-\ndrivers/s390/crypto/vfio_ap_drv.c:67:static void vfio_ap_matrix_dev_release(struct device dev)\ndrivers/s390/crypto/vfio_ap_drv.c-68-{\ndrivers/s390/crypto/vfio_ap_drv.c:69:\tstruct ap_matrix_dev matrix_dev;\ndrivers/s390/crypto/vfio_ap_drv.c-70-\ndrivers/s390/crypto/vfio_ap_drv.c:71:\tmatrix_dev = container_of(dev, struct ap_matrix_dev, device);\ndrivers/s390/crypto/vfio_ap_drv.c:72:\tkfree(matrix_dev);\ndrivers/s390/crypto/vfio_ap_drv.c-73-}\n--\ndrivers/s390/crypto/vfio_ap_drv.c=79=static struct device_driver matrix_driver = {\n--\ndrivers/s390/crypto/vfio_ap_drv.c-82-\t.suppress_bind_attrs = true,\ndrivers/s390/crypto/vfio_ap_drv.c:83:\t.dev_groups = matrix_dev_groups,\ndrivers/s390/crypto/vfio_ap_drv.c-84-};\ndrivers/s390/crypto/vfio_ap_drv.c-85-\ndrivers/s390/crypto/vfio_ap_drv.c:86:static int vfio_ap_matrix_dev_create(void)\ndrivers/s390/crypto/vfio_ap_drv.c-87-{\n--\ndrivers/s390/crypto/vfio_ap_drv.c-98-\ndrivers/s390/crypto/vfio_ap_drv.c:99:\tmatrix_dev = kzalloc_obj(matrix_dev);\ndrivers/s390/crypto/vfio_ap_drv.c:100:\tif (!matrix_dev) {\ndrivers/s390/crypto/vfio_ap_drv.c-101-\t\tret = -ENOMEM;\n--\ndrivers/s390/crypto/vfio_ap_drv.c-106-\tif (test_facility(12)) {\ndrivers/s390/crypto/vfio_ap_drv.c:107:\t\tret = ap_qci(\u0026matrix_dev-\u003einfo);\ndrivers/s390/crypto/vfio_ap_drv.c-108-\t\tif (ret)\n--\ndrivers/s390/crypto/vfio_ap_drv.c-111-\ndrivers/s390/crypto/vfio_ap_drv.c:112:\tmutex_init(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_drv.c:113:\tINIT_LIST_HEAD(\u0026matrix_dev-\u003emdev_list);\ndrivers/s390/crypto/vfio_ap_drv.c:114:\tmutex_init(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_drv.c-115-\ndrivers/s390/crypto/vfio_ap_drv.c:116:\tdev_set_name(\u0026matrix_dev-\u003edevice, \"%s\", VFIO_AP_DEV_NAME);\ndrivers/s390/crypto/vfio_ap_drv.c:117:\tmatrix_dev-\u003edevice.parent = root_device;\ndrivers/s390/crypto/vfio_ap_drv.c:118:\tmatrix_dev-\u003edevice.bus = \u0026matrix_bus;\ndrivers/s390/crypto/vfio_ap_drv.c:119:\tmatrix_dev-\u003edevice.release = vfio_ap_matrix_dev_release;\ndrivers/s390/crypto/vfio_ap_drv.c:120:\tmatrix_dev-\u003evfio_ap_drv = \u0026vfio_ap_drv;\ndrivers/s390/crypto/vfio_ap_drv.c-121-\ndrivers/s390/crypto/vfio_ap_drv.c:122:\tret = device_register(\u0026matrix_dev-\u003edevice);\ndrivers/s390/crypto/vfio_ap_drv.c-123-\tif (ret)\n--\ndrivers/s390/crypto/vfio_ap_drv.c-132-matrix_drv_err:\ndrivers/s390/crypto/vfio_ap_drv.c:133:\tdevice_del(\u0026matrix_dev-\u003edevice);\ndrivers/s390/crypto/vfio_ap_drv.c-134-matrix_reg_err:\ndrivers/s390/crypto/vfio_ap_drv.c:135:\tput_device(\u0026matrix_dev-\u003edevice);\ndrivers/s390/crypto/vfio_ap_drv.c-136-matrix_alloc_err:\n--\ndrivers/s390/crypto/vfio_ap_drv.c-142-\ndrivers/s390/crypto/vfio_ap_drv.c:143:static void vfio_ap_matrix_dev_destroy(void)\ndrivers/s390/crypto/vfio_ap_drv.c-144-{\ndrivers/s390/crypto/vfio_ap_drv.c:145:\tstruct device root_device = matrix_dev-\u003edevice.parent;\ndrivers/s390/crypto/vfio_ap_drv.c-146-\ndrivers/s390/crypto/vfio_ap_drv.c-147-\tdriver_unregister(\u0026matrix_driver);\ndrivers/s390/crypto/vfio_ap_drv.c:148:\tdevice_unregister(\u0026matrix_dev-\u003edevice);\ndrivers/s390/crypto/vfio_ap_drv.c-149-\tbus_unregister(\u0026matrix_bus);\n--\ndrivers/s390/crypto/vfio_ap_drv.c=167=static int __init vfio_ap_init(void)\n--\ndrivers/s390/crypto/vfio_ap_drv.c-178-\ndrivers/s390/crypto/vfio_ap_drv.c:179:\tret = vfio_ap_matrix_dev_create();\ndrivers/s390/crypto/vfio_ap_drv.c-180-\tif (ret)\n--\ndrivers/s390/crypto/vfio_ap_drv.c-184-\tif (ret) {\ndrivers/s390/crypto/vfio_ap_drv.c:185:\t\tvfio_ap_matrix_dev_destroy();\ndrivers/s390/crypto/vfio_ap_drv.c-186-\t\treturn ret;\n--\ndrivers/s390/crypto/vfio_ap_drv.c-191-\t\tap_driver_unregister(\u0026vfio_ap_drv);\ndrivers/s390/crypto/vfio_ap_drv.c:192:\t\tvfio_ap_matrix_dev_destroy();\ndrivers/s390/crypto/vfio_ap_drv.c-193-\n--\ndrivers/s390/crypto/vfio_ap_drv.c=200=static void __exit vfio_ap_exit(void)\n--\ndrivers/s390/crypto/vfio_ap_drv.c-203-\tap_driver_unregister(\u0026vfio_ap_drv);\ndrivers/s390/crypto/vfio_ap_drv.c:204:\tvfio_ap_matrix_dev_destroy();\ndrivers/s390/crypto/vfio_ap_drv.c-205-\tdebug_unregister(vfio_ap_dbf_info);\n--\ndrivers/s390/crypto/vfio_ap_ops.c=37=static struct vfio_ap_queue vfio_ap_find_queue(int apqn);\ndrivers/s390/crypto/vfio_ap_ops.c:38:static const struct vfio_device_ops vfio_ap_matrix_dev_ops;\ndrivers/s390/crypto/vfio_ap_ops.c-39-static void vfio_ap_mdev_reset_queue(struct vfio_ap_queue q);\n--\ndrivers/s390/crypto/vfio_ap_ops.c-47- The proper locking order is:\ndrivers/s390/crypto/vfio_ap_ops.c:48: * 1. matrix_dev-\u003eguests_lock: required to use the KVM pointer to update a KVM\ndrivers/s390/crypto/vfio_ap_ops.c-49- \t\t\t guest's APCB.\n--\ndrivers/s390/crypto/vfio_ap_ops.c-52- \t\t\t\t\tserialize against PQAP intercepts\ndrivers/s390/crypto/vfio_ap_ops.c:53: * 4. matrix_dev-\u003emdevs_lock: required to access data stored in a matrix_mdev\ndrivers/s390/crypto/vfio_ap_ops.c-54- \n--\ndrivers/s390/crypto/vfio_ap_ops.c=57=static inline void get_update_locks_for_kvm(struct kvm kvm)\ndrivers/s390/crypto/vfio_ap_ops.c-58-{\ndrivers/s390/crypto/vfio_ap_ops.c:59:\tmutex_lock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-60-\tif (kvm) {\n--\ndrivers/s390/crypto/vfio_ap_ops.c-63-\t}\ndrivers/s390/crypto/vfio_ap_ops.c:64:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-65-}\n--\ndrivers/s390/crypto/vfio_ap_ops.c-73- * The proper unlocking order is:\ndrivers/s390/crypto/vfio_ap_ops.c:74: * 1. matrix_dev-\u003emdevs_lock\ndrivers/s390/crypto/vfio_ap_ops.c-75- * 2. kvm-\u003earch.crypto.pqap_hook_rwsem\ndrivers/s390/crypto/vfio_ap_ops.c-76- * 3. kvm-\u003elock\ndrivers/s390/crypto/vfio_ap_ops.c:77: * 4. matrix_dev-\u003eguests_lock\ndrivers/s390/crypto/vfio_ap_ops.c-78- \n--\ndrivers/s390/crypto/vfio_ap_ops.c=81=static inline void release_update_locks_for_kvm(struct kvm kvm)\ndrivers/s390/crypto/vfio_ap_ops.c-82-{\ndrivers/s390/crypto/vfio_ap_ops.c:83:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-84-\tif (kvm) {\n--\ndrivers/s390/crypto/vfio_ap_ops.c-87-\t}\ndrivers/s390/crypto/vfio_ap_ops.c:88:\tmutex_unlock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-89-}\n--\ndrivers/s390/crypto/vfio_ap_ops.c-98- * The proper locking order is:\ndrivers/s390/crypto/vfio_ap_ops.c:99: * 1. matrix_dev-\u003eguests_lock: required to use the KVM pointer to update a KVM\ndrivers/s390/crypto/vfio_ap_ops.c-100- \t\t\t guest's APCB.\ndrivers/s390/crypto/vfio_ap_ops.c-101- 2. matrix_mdev-\u003ekvm-\u003elock: required to update a guest's APCB\ndrivers/s390/crypto/vfio_ap_ops.c:102: * 3. matrix_dev-\u003emdevs_lock: required to access data stored in a matrix_mdev\ndrivers/s390/crypto/vfio_ap_ops.c-103- \n--\ndrivers/s390/crypto/vfio_ap_ops.c=107=static inline void get_update_locks_for_mdev(struct ap_matrix_mdev matrix_mdev)\ndrivers/s390/crypto/vfio_ap_ops.c-108-{\ndrivers/s390/crypto/vfio_ap_ops.c:109:\tmutex_lock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-110-\tif (matrix_mdev \u0026\u0026 matrix_mdev-\u003ekvm)\ndrivers/s390/crypto/vfio_ap_ops.c-111-\t\tmutex_lock(\u0026matrix_mdev-\u003ekvm-\u003elock);\ndrivers/s390/crypto/vfio_ap_ops.c:112:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-113-}\n--\ndrivers/s390/crypto/vfio_ap_ops.c-122- * The proper unlocking order is:\ndrivers/s390/crypto/vfio_ap_ops.c:123: * 1. matrix_dev-\u003emdevs_lock\ndrivers/s390/crypto/vfio_ap_ops.c-124- * 2. matrix_mdev-\u003ekvm-\u003elock\ndrivers/s390/crypto/vfio_ap_ops.c:125: * 3. matrix_dev-\u003eguests_lock\ndrivers/s390/crypto/vfio_ap_ops.c-126- \n--\ndrivers/s390/crypto/vfio_ap_ops.c=130=static inline void release_update_locks_for_mdev(struct ap_matrix_mdev matrix_mdev)\ndrivers/s390/crypto/vfio_ap_ops.c-131-{\ndrivers/s390/crypto/vfio_ap_ops.c:132:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-133-\tif (matrix_mdev \u0026\u0026 matrix_mdev-\u003ekvm)\ndrivers/s390/crypto/vfio_ap_ops.c-134-\t\tmutex_unlock(\u0026matrix_mdev-\u003ekvm-\u003elock);\ndrivers/s390/crypto/vfio_ap_ops.c:135:\tmutex_unlock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-136-}\n--\ndrivers/s390/crypto/vfio_ap_ops.c-145- * The proper locking order is:\ndrivers/s390/crypto/vfio_ap_ops.c:146: * 1. matrix_dev-\u003eguests_lock: required to use the KVM pointer to update a KVM\ndrivers/s390/crypto/vfio_ap_ops.c-147- \t\t\t guest's APCB.\ndrivers/s390/crypto/vfio_ap_ops.c-148- 2. matrix_mdev-\u003ekvm-\u003elock: required to update a guest's APCB\ndrivers/s390/crypto/vfio_ap_ops.c:149: * 3. matrix_dev-\u003emdevs_lock: required to access data stored in a matrix_mdev\ndrivers/s390/crypto/vfio_ap_ops.c-150- \n--\ndrivers/s390/crypto/vfio_ap_ops.c=157=static struct ap_matrix_mdev get_update_locks_by_apqn(int apqn)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-160-\ndrivers/s390/crypto/vfio_ap_ops.c:161:\tmutex_lock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-162-\ndrivers/s390/crypto/vfio_ap_ops.c:163:\tlist_for_each_entry(matrix_mdev, \u0026matrix_dev-\u003emdev_list, node) {\ndrivers/s390/crypto/vfio_ap_ops.c-164-\t\tif (test_bit_inv(AP_QID_CARD(apqn), matrix_mdev-\u003ematrix.apm) \u0026\u0026\n--\ndrivers/s390/crypto/vfio_ap_ops.c-168-\ndrivers/s390/crypto/vfio_ap_ops.c:169:\t\t\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-170-\n--\ndrivers/s390/crypto/vfio_ap_ops.c-174-\ndrivers/s390/crypto/vfio_ap_ops.c:175:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-176-\n--\ndrivers/s390/crypto/vfio_ap_ops.c-187- * The proper locking order is:\ndrivers/s390/crypto/vfio_ap_ops.c:188: * 1. q-\u003ematrix_dev-\u003eguests_lock: required to use the KVM pointer to update a\ndrivers/s390/crypto/vfio_ap_ops.c-189- \t\t\t\t KVM guest's APCB.\ndrivers/s390/crypto/vfio_ap_ops.c-190- 2. q-\u003ematrix_mdev-\u003ekvm-\u003elock: required to update a guest's APCB\ndrivers/s390/crypto/vfio_ap_ops.c:191: * 3. matrix_dev-\u003emdevs_lock:\t required to access data stored in matrix_mdev\ndrivers/s390/crypto/vfio_ap_ops.c-192- \n--\ndrivers/s390/crypto/vfio_ap_ops.c=196=static inline void get_update_locks_for_queue(struct vfio_ap_queue q)\ndrivers/s390/crypto/vfio_ap_ops.c-197-{\ndrivers/s390/crypto/vfio_ap_ops.c:198:\tmutex_lock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-199-\tif (q-\u003ematrix_mdev \u0026\u0026 q-\u003ematrix_mdev-\u003ekvm)\ndrivers/s390/crypto/vfio_ap_ops.c-200-\t\tmutex_lock(\u0026q-\u003ematrix_mdev-\u003ekvm-\u003elock);\ndrivers/s390/crypto/vfio_ap_ops.c:201:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-202-}\n--\ndrivers/s390/crypto/vfio_ap_ops.c=552=static void vfio_ap_le_guid_to_be_uuid(guid_t guid, unsigned long uuid)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-581- * Check vfio_ap_setirq() and vfio_ap_clrirq() for other possible RC.\ndrivers/s390/crypto/vfio_ap_ops.c:582: * We take the matrix_dev lock to ensure serialization on queues and\ndrivers/s390/crypto/vfio_ap_ops.c-583- * mediated device access.\n--\ndrivers/s390/crypto/vfio_ap_ops.c=588=static int handle_pqap(struct kvm_vcpu vcpu)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-607-\ndrivers/s390/crypto/vfio_ap_ops.c:608:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-609-\n--\ndrivers/s390/crypto/vfio_ap_ops.c-647-\tvcpu-\u003erun-\u003es.regs.gprs[1] \u003e\u003e= 32;\ndrivers/s390/crypto/vfio_ap_ops.c:648:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-649-\treturn 0;\n--\ndrivers/s390/crypto/vfio_ap_ops.c=678=static bool vfio_ap_mdev_filter_cdoms(struct ap_matrix_mdev matrix_mdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-683-\tbitmap_and(matrix_mdev-\u003eshadow_apcb.adm, matrix_mdev-\u003ematrix.adm,\ndrivers/s390/crypto/vfio_ap_ops.c:684:\t\t (unsigned long )matrix_dev-\u003einfo.adm, AP_DOMAINS);\ndrivers/s390/crypto/vfio_ap_ops.c-685-\n--\ndrivers/s390/crypto/vfio_ap_ops.c=727=static bool vfio_ap_mdev_filter_matrix(struct ap_matrix_mdev matrix_mdev,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-735-\tbitmap_copy(prev_shadow_aqm, matrix_mdev-\u003eshadow_apcb.aqm, AP_DOMAINS);\ndrivers/s390/crypto/vfio_ap_ops.c:736:\tvfio_ap_matrix_init(\u0026matrix_dev-\u003einfo, \u0026matrix_mdev-\u003eshadow_apcb);\ndrivers/s390/crypto/vfio_ap_ops.c-737-\tbitmap_clear(apm_filtered, 0, AP_DEVICES);\n--\ndrivers/s390/crypto/vfio_ap_ops.c-744-\tbitmap_and(matrix_mdev-\u003eshadow_apcb.apm, matrix_mdev-\u003ematrix.apm,\ndrivers/s390/crypto/vfio_ap_ops.c:745:\t\t (unsigned long )matrix_dev-\u003einfo.apm, AP_DEVICES);\ndrivers/s390/crypto/vfio_ap_ops.c-746-\tbitmap_and(matrix_mdev-\u003eshadow_apcb.aqm, matrix_mdev-\u003ematrix.aqm,\ndrivers/s390/crypto/vfio_ap_ops.c:747:\t\t (unsigned long )matrix_dev-\u003einfo.aqm, AP_DOMAINS);\ndrivers/s390/crypto/vfio_ap_ops.c-748-\n--\ndrivers/s390/crypto/vfio_ap_ops.c=783=static int vfio_ap_mdev_init_dev(struct vfio_device vdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-788-\tmatrix_mdev-\u003emdev = to_mdev_device(vdev-\u003edev);\ndrivers/s390/crypto/vfio_ap_ops.c:789:\tvfio_ap_matrix_init(\u0026matrix_dev-\u003einfo, \u0026matrix_mdev-\u003ematrix);\ndrivers/s390/crypto/vfio_ap_ops.c-790-\tmatrix_mdev-\u003epqap_hook = handle_pqap;\ndrivers/s390/crypto/vfio_ap_ops.c:791:\tvfio_ap_matrix_init(\u0026matrix_dev-\u003einfo, \u0026matrix_mdev-\u003eshadow_apcb);\ndrivers/s390/crypto/vfio_ap_ops.c-792-\thash_init(matrix_mdev-\u003eqtable.queues);\n--\ndrivers/s390/crypto/vfio_ap_ops.c=797=static int vfio_ap_mdev_probe(struct mdev_device mdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-802-\tmatrix_mdev = vfio_alloc_device(ap_matrix_mdev, vdev, \u0026mdev-\u003edev,\ndrivers/s390/crypto/vfio_ap_ops.c:803:\t\t\t\t\t\u0026vfio_ap_matrix_dev_ops);\ndrivers/s390/crypto/vfio_ap_ops.c-804-\tif (IS_ERR(matrix_mdev))\n--\ndrivers/s390/crypto/vfio_ap_ops.c-812-\tdev_set_drvdata(\u0026mdev-\u003edev, matrix_mdev);\ndrivers/s390/crypto/vfio_ap_ops.c:813:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c:814:\tlist_add(\u0026matrix_mdev-\u003enode, \u0026matrix_dev-\u003emdev_list);\ndrivers/s390/crypto/vfio_ap_ops.c:815:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-816-\treturn 0;\n--\ndrivers/s390/crypto/vfio_ap_ops.c=867=static void vfio_ap_mdev_remove(struct mdev_device mdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-872-\ndrivers/s390/crypto/vfio_ap_ops.c:873:\tmutex_lock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c:874:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-875-\tvfio_ap_mdev_reset_queues(matrix_mdev);\n--\ndrivers/s390/crypto/vfio_ap_ops.c-877-\tlist_del(\u0026matrix_mdev-\u003enode);\ndrivers/s390/crypto/vfio_ap_ops.c:878:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c:879:\tmutex_unlock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-880-\tvfio_put_device(\u0026matrix_mdev-\u003evdev);\n--\ndrivers/s390/crypto/vfio_ap_ops.c=929=static int vfio_ap_mdev_verify_no_sharing(struct ap_matrix_mdev assignee,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-936-\ndrivers/s390/crypto/vfio_ap_ops.c:937:\tlist_for_each_entry(assigned_to, \u0026matrix_dev-\u003emdev_list, node) {\ndrivers/s390/crypto/vfio_ap_ops.c-938-\t\t/\n--\ndrivers/s390/crypto/vfio_ap_ops.c=1568=static ssize_t control_domains_show(struct device dev,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1576-\ndrivers/s390/crypto/vfio_ap_ops.c:1577:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-1578-\tfor_each_set_bit_inv(id, matrix_mdev-\u003ematrix.adm, max_domid + 1)\ndrivers/s390/crypto/vfio_ap_ops.c-1579-\t\tnchars += sysfs_emit_at(buf, nchars, \"%04lx\\n\", id);\ndrivers/s390/crypto/vfio_ap_ops.c:1580:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-1581-\n--\ndrivers/s390/crypto/vfio_ap_ops.c=1615=static ssize_t matrix_show(struct device dev, struct device_attribute attr,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1620-\ndrivers/s390/crypto/vfio_ap_ops.c:1621:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-1622-\tnchars = vfio_ap_mdev_matrix_show(\u0026matrix_mdev-\u003ematrix, buf);\ndrivers/s390/crypto/vfio_ap_ops.c:1623:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-1624-\n--\ndrivers/s390/crypto/vfio_ap_ops.c=1629=static ssize_t guest_matrix_show(struct device dev,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1634-\ndrivers/s390/crypto/vfio_ap_ops.c:1635:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-1636-\tnchars = vfio_ap_mdev_matrix_show(\u0026matrix_mdev-\u003eshadow_apcb, buf);\ndrivers/s390/crypto/vfio_ap_ops.c:1637:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-1638-\n--\ndrivers/s390/crypto/vfio_ap_ops.c=1860=static void vfio_ap_mdev_dma_unmap(struct vfio_device vdev, u64 iova,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1865-\ndrivers/s390/crypto/vfio_ap_ops.c:1866:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-1867-\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1869-\ndrivers/s390/crypto/vfio_ap_ops.c:1870:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-1871-}\n--\ndrivers/s390/crypto/vfio_ap_ops.c=1896=static struct vfio_ap_queue vfio_ap_find_queue(int apqn)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1904-\ndrivers/s390/crypto/vfio_ap_ops.c:1905:\tif (queue-\u003eap_dev.device.driver == \u0026matrix_dev-\u003evfio_ap_drv-\u003edriver)\ndrivers/s390/crypto/vfio_ap_ops.c-1906-\t\tq = dev_get_drvdata(\u0026queue-\u003eap_dev.device);\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2259=static ssize_t vfio_ap_mdev_ioctl(struct vfio_device vdev,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2265-\ndrivers/s390/crypto/vfio_ap_ops.c:2266:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2267-\tswitch (cmd) {\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2283-\t}\ndrivers/s390/crypto/vfio_ap_ops.c:2284:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2285-\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2289=static struct ap_matrix_mdev vfio_ap_mdev_for_queue(struct vfio_ap_queue q)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2294-\ndrivers/s390/crypto/vfio_ap_ops.c:2295:\tlist_for_each_entry(matrix_mdev, \u0026matrix_dev-\u003emdev_list, node) {\ndrivers/s390/crypto/vfio_ap_ops.c-2296-\t\tif (test_bit_inv(apid, matrix_mdev-\u003ematrix.apm) \u0026\u0026\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2304=static ssize_t status_show(struct device dev,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2313-\ndrivers/s390/crypto/vfio_ap_ops.c:2314:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2315-\tq = dev_get_drvdata(\u0026apdev-\u003edevice);\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2339-\ndrivers/s390/crypto/vfio_ap_ops.c:2340:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2341-\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2352=static const struct attribute_group vfio_queue_attr_group = {\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2355-\ndrivers/s390/crypto/vfio_ap_ops.c:2356:static const struct vfio_device_ops vfio_ap_matrix_dev_ops = {\ndrivers/s390/crypto/vfio_ap_ops.c-2357-\t.init = vfio_ap_mdev_init_dev,\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2382=int vfio_ap_mdev_register(void)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2389-\ndrivers/s390/crypto/vfio_ap_ops.c:2390:\tmatrix_dev-\u003emdev_type.sysfs_name = VFIO_AP_MDEV_TYPE_HWVIRT;\ndrivers/s390/crypto/vfio_ap_ops.c:2391:\tmatrix_dev-\u003emdev_type.pretty_name = VFIO_AP_MDEV_NAME_HWVIRT;\ndrivers/s390/crypto/vfio_ap_ops.c:2392:\tmatrix_dev-\u003emdev_types = \u0026matrix_dev-\u003emdev_type;\ndrivers/s390/crypto/vfio_ap_ops.c:2393:\tret = mdev_register_parent(\u0026matrix_dev-\u003eparent, \u0026matrix_dev-\u003edevice,\ndrivers/s390/crypto/vfio_ap_ops.c-2394-\t\t\t\t \u0026vfio_ap_matrix_driver,\ndrivers/s390/crypto/vfio_ap_ops.c:2395:\t\t\t\t \u0026matrix_dev-\u003emdev_types, 1);\ndrivers/s390/crypto/vfio_ap_ops.c-2396-\tif (ret)\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2405=void vfio_ap_mdev_unregister(void)\ndrivers/s390/crypto/vfio_ap_ops.c-2406-{\ndrivers/s390/crypto/vfio_ap_ops.c:2407:\tmdev_unregister_parent(\u0026matrix_dev-\u003eparent);\ndrivers/s390/crypto/vfio_ap_ops.c-2408-\tmdev_unregister_driver(\u0026vfio_ap_matrix_driver);\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2465=void vfio_ap_mdev_remove_queue(struct ap_device apdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2498-\t /\ndrivers/s390/crypto/vfio_ap_ops.c:2499:\tif (test_bit_inv(apid, (unsigned long )matrix_dev-\u003einfo.apm) \u0026\u0026\ndrivers/s390/crypto/vfio_ap_ops.c:2500:\t test_bit_inv(apqi, (unsigned long )matrix_dev-\u003einfo.aqm)) {\ndrivers/s390/crypto/vfio_ap_ops.c-2501-\t\tvfio_ap_mdev_reset_queue(q);\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2528=int vfio_ap_mdev_resource_in_use(unsigned long apm, unsigned long aqm)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2531-\ndrivers/s390/crypto/vfio_ap_ops.c:2532:\tmutex_lock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c:2533:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2534-\tret = vfio_ap_mdev_verify_no_sharing(NULL, apm, aqm);\ndrivers/s390/crypto/vfio_ap_ops.c:2535:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c:2536:\tmutex_unlock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2537-\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2593=static void vfio_ap_mdev_cfg_remove(unsigned long ap_remove,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2602-\ndrivers/s390/crypto/vfio_ap_ops.c:2603:\tlist_for_each_entry(matrix_mdev, \u0026matrix_dev-\u003emdev_list, node) {\ndrivers/s390/crypto/vfio_ap_ops.c-2604-\t\tmutex_lock(\u0026matrix_mdev-\u003ekvm-\u003elock);\ndrivers/s390/crypto/vfio_ap_ops.c:2605:\t\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2606-\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2620-\ndrivers/s390/crypto/vfio_ap_ops.c:2621:\t\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2622-\t\tmutex_unlock(\u0026matrix_mdev-\u003ekvm-\u003elock);\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2736=static void vfio_ap_mdev_cfg_add(unsigned long apm_add, unsigned long aqm_add,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2740-\ndrivers/s390/crypto/vfio_ap_ops.c:2741:\tif (list_empty(\u0026matrix_dev-\u003emdev_list))\ndrivers/s390/crypto/vfio_ap_ops.c-2742-\t\treturn;\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2745-\ndrivers/s390/crypto/vfio_ap_ops.c:2746:\tlist_for_each_entry(matrix_mdev, \u0026matrix_dev-\u003emdev_list, node) {\ndrivers/s390/crypto/vfio_ap_ops.c-2747-\t\tbitmap_and(matrix_mdev-\u003eapm_add,\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2799=void vfio_ap_on_cfg_changed(struct ap_config_info cur_cfg_info,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2804-\ndrivers/s390/crypto/vfio_ap_ops.c:2805:\tmutex_lock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2806-\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2808-\tvfio_ap_mdev_on_cfg_add(cur_cfg_info, prev_cfg_info);\ndrivers/s390/crypto/vfio_ap_ops.c:2809:\tmemcpy(\u0026matrix_dev-\u003einfo, cur_cfg_info, sizeof(cur_cfg_info));\ndrivers/s390/crypto/vfio_ap_ops.c-2810-\ndrivers/s390/crypto/vfio_ap_ops.c:2811:\tmutex_unlock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2812-}\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2814=static void vfio_ap_mdev_hot_plug_cfg(struct ap_matrix_mdev matrix_mdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2819-\tmutex_lock(\u0026matrix_mdev-\u003ekvm-\u003elock);\ndrivers/s390/crypto/vfio_ap_ops.c:2820:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2821-\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2839-\ndrivers/s390/crypto/vfio_ap_ops.c:2840:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2841-\tmutex_unlock(\u0026matrix_mdev-\u003ekvm-\u003elock);\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2844=void vfio_ap_on_scan_complete(struct ap_config_info new_config_info,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2848-\ndrivers/s390/crypto/vfio_ap_ops.c:2849:\tmutex_lock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2850-\ndrivers/s390/crypto/vfio_ap_ops.c:2851:\tlist_for_each_entry(matrix_mdev, \u0026matrix_dev-\u003emdev_list, node) {\ndrivers/s390/crypto/vfio_ap_ops.c-2852-\t\tif (bitmap_empty(matrix_mdev-\u003eapm_add, AP_DEVICES) \u0026\u0026\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2862-\ndrivers/s390/crypto/vfio_ap_ops.c:2863:\tmutex_unlock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2864-}\n--\ndrivers/s390/crypto/vfio_ap_private.h-29-/*\ndrivers/s390/crypto/vfio_ap_private.h:30: struct ap_matrix_dev - Contains the data for the matrix device.\ndrivers/s390/crypto/vfio_ap_private.h-31- \n--\ndrivers/s390/crypto/vfio_ap_private.h-46- /\ndrivers/s390/crypto/vfio_ap_private.h:47:struct ap_matrix_dev {\ndrivers/s390/crypto/vfio_ap_private.h-48-\tstruct device device;\n--\ndrivers/s390/crypto/vfio_ap_private.h-58-\ndrivers/s390/crypto/vfio_ap_private.h:59:extern struct ap_matrix_dev *matrix_dev;\ndrivers/s390/crypto/vfio_ap_private.h-60-\n" }
11/2	2026/08/06 21:15	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 19328 output: 18 thoughts: 166 Thoughts: My Initial Thoughts on VFIO-AP Device Creation Okay, so I'm tracing the VFIO-AP initialization. I see that `vfio_ap_matrix_dev_create` is called during module init within `vfio_ap_init`. That makes sense; it's registering a matrix device, the foundational element. Then, `vfio_ap_mdev_probe` gets called when a new mdev is created. I have to pause here. I wonder, can these mdevs, these software representations, even be created within a virtualized environment? Oh right, they're just software devices, created through sysfs, so logically, yes. But hang on, there’s something important I need to consider. I'm focusing back on `vfio_ap_matrix_dev_create`. It looks like it calls `ap_qci(&matrix_dev->info)` under the condition that `test_facility(12)` evaluates to true. Facility 12 is AP Query Configuration Information. Now, the next question is if that facility is not available, will this whole process just fall apart? I need to check the code in `vfio_ap_matrix_dev_create` to ensure.
12/2	2026/08/06 21:15	tool	grepper	0m Args: { "Expression": "ap_qci" } Results: { "Output": "arch/s390/include/asm/ap.h=217=static inline struct ap_queue_status ap_zapq(ap_qid_t qid, int fbit)\n--\narch/s390/include/asm/ap.h-236- * struct ap_config_info - convenience struct for AP crypto\narch/s390/include/asm/ap.h:237: * config info as returned by the ap_qci() function.\narch/s390/include/asm/ap.h-238- /\narch/s390/include/asm/ap.h=239=struct ap_config_info {\n--\narch/s390/include/asm/ap.h-261-/\narch/s390/include/asm/ap.h:262: ap_qci(): Get AP configuration data\narch/s390/include/asm/ap.h-263- \n--\narch/s390/include/asm/ap.h-265- /\narch/s390/include/asm/ap.h:266:static inline int ap_qci(struct ap_config_info config)\narch/s390/include/asm/ap.h-267-{\n--\narch/s390/kvm/kvm-s390.c=3101=static int kvm_s390_apxa_installed(void)\n--\narch/s390/kvm/kvm-s390.c-3105-\tif (ap_instructions_available()) {\narch/s390/kvm/kvm-s390.c:3106:\t\tif (ap_qci(\u0026info) == 0)\narch/s390/kvm/kvm-s390.c-3107-\t\t\treturn info.apxa;\n--\ndrivers/s390/crypto/ap_bus.c=107=static struct ap_config_info qci[2];\ndrivers/s390/crypto/ap_bus.c:108:static struct ap_config_info const ap_qci_info = \u0026qci[0];\ndrivers/s390/crypto/ap_bus.c:109:static struct ap_config_info const ap_qci_info_old = \u0026qci[1];\ndrivers/s390/crypto/ap_bus.c-110-\n--\ndrivers/s390/crypto/ap_bus.c=209=static int ap_interrupts_available(void)\n--\ndrivers/s390/crypto/ap_bus.c-214-/\ndrivers/s390/crypto/ap_bus.c:215: ap_qci_available(): Test if AP configuration\ndrivers/s390/crypto/ap_bus.c-216- * information can be queried via QCI subfunction.\n--\ndrivers/s390/crypto/ap_bus.c-219- /\ndrivers/s390/crypto/ap_bus.c:220:static int ap_qci_available(void)\ndrivers/s390/crypto/ap_bus.c-221-{\n--\ndrivers/s390/crypto/ap_bus.c=241=static inline int ap_qact_available(void)\ndrivers/s390/crypto/ap_bus.c-242-{\ndrivers/s390/crypto/ap_bus.c:243:\treturn ap_qci_info-\u003eqact;\ndrivers/s390/crypto/ap_bus.c-244-}\n--\ndrivers/s390/crypto/ap_bus.c=251=int ap_sb_available(void)\ndrivers/s390/crypto/ap_bus.c-252-{\ndrivers/s390/crypto/ap_bus.c:253:\treturn ap_qci_info-\u003eapsb;\ndrivers/s390/crypto/ap_bus.c-254-}\n--\ndrivers/s390/crypto/ap_bus.c=270=static void __init ap_init_qci_info(void)\ndrivers/s390/crypto/ap_bus.c-271-{\ndrivers/s390/crypto/ap_bus.c:272:\tif (!ap_qci_available() \|\|\ndrivers/s390/crypto/ap_bus.c:273:\t ap_qci(ap_qci_info)) {\ndrivers/s390/crypto/ap_bus.c-274-\t\tAP_DBF_INFO(\"%s QCI not supported\\n\", __func__);\n--\ndrivers/s390/crypto/ap_bus.c-276-\t}\ndrivers/s390/crypto/ap_bus.c:277:\tmemcpy(ap_qci_info_old, ap_qci_info, sizeof(ap_qci_info));\ndrivers/s390/crypto/ap_bus.c-278-\tAP_DBF_INFO(\"%s successful fetched initial qci info\\n\", __func__);\ndrivers/s390/crypto/ap_bus.c-279-\ndrivers/s390/crypto/ap_bus.c:280:\tif (ap_qci_info-\u003eapxa) {\ndrivers/s390/crypto/ap_bus.c:281:\t\tif (ap_qci_info-\u003ena) {\ndrivers/s390/crypto/ap_bus.c:282:\t\t\tap_max_adapter_id = ap_qci_info-\u003ena;\ndrivers/s390/crypto/ap_bus.c-283-\t\t\tAP_DBF_INFO(\"%s new ap_max_adapter_id is %d\\n\",\n--\ndrivers/s390/crypto/ap_bus.c-285-\t\t}\ndrivers/s390/crypto/ap_bus.c:286:\t\tif (ap_qci_info-\u003end) {\ndrivers/s390/crypto/ap_bus.c:287:\t\t\tap_max_domain_id = ap_qci_info-\u003end;\ndrivers/s390/crypto/ap_bus.c-288-\t\t\tAP_DBF_INFO(\"%s new ap_max_domain_id is %d\\n\",\n--\ndrivers/s390/crypto/ap_bus.c=310=static inline int ap_test_config_card_id(unsigned int id)\n--\ndrivers/s390/crypto/ap_bus.c-313-\t\treturn 0;\ndrivers/s390/crypto/ap_bus.c:314:\tif (ap_qci_info-\u003eflags)\ndrivers/s390/crypto/ap_bus.c:315:\t\treturn ap_test_config(ap_qci_info-\u003eapm, id);\ndrivers/s390/crypto/ap_bus.c-316-\treturn 1;\n--\ndrivers/s390/crypto/ap_bus.c=327=int ap_test_config_usage_domain(unsigned int domain)\n--\ndrivers/s390/crypto/ap_bus.c-330-\t\treturn 0;\ndrivers/s390/crypto/ap_bus.c:331:\tif (ap_qci_info-\u003eflags)\ndrivers/s390/crypto/ap_bus.c:332:\t\treturn ap_test_config(ap_qci_info-\u003eaqm, domain);\ndrivers/s390/crypto/ap_bus.c-333-\treturn 1;\n--\ndrivers/s390/crypto/ap_bus.c=345=int ap_test_config_ctrl_domain(unsigned int domain)\ndrivers/s390/crypto/ap_bus.c-346-{\ndrivers/s390/crypto/ap_bus.c:347:\tif (!ap_qci_info \|\| domain \u003e ap_max_domain_id)\ndrivers/s390/crypto/ap_bus.c-348-\t\treturn 0;\ndrivers/s390/crypto/ap_bus.c:349:\treturn ap_test_config(ap_qci_info-\u003eadm, domain);\ndrivers/s390/crypto/ap_bus.c-350-}\n--\ndrivers/s390/crypto/ap_bus.c=1349=static ssize_t ap_control_domain_mask_show(const struct bus_type bus, char buf)\ndrivers/s390/crypto/ap_bus.c-1350-{\ndrivers/s390/crypto/ap_bus.c:1351:\tif (!ap_qci_info-\u003eflags)\t/* QCI not supported /\ndrivers/s390/crypto/ap_bus.c-1352-\t\treturn sysfs_emit(buf, \"not supported\\n\");\n--\ndrivers/s390/crypto/ap_bus.c-1354-\treturn sysfs_emit(buf, \"0x%08x%08x%08x%08x%08x%08x%08x%08x\\n\",\ndrivers/s390/crypto/ap_bus.c:1355:\t\t\t ap_qci_info-\u003eadm[0], ap_qci_info-\u003eadm[1],\ndrivers/s390/crypto/ap_bus.c:1356:\t\t\t ap_qci_info-\u003eadm[2], ap_qci_info-\u003eadm[3],\ndrivers/s390/crypto/ap_bus.c:1357:\t\t\t ap_qci_info-\u003eadm[4], ap_qci_info-\u003eadm[5],\ndrivers/s390/crypto/ap_bus.c:1358:\t\t\t ap_qci_info-\u003eadm[6], ap_qci_info-\u003eadm[7]);\ndrivers/s390/crypto/ap_bus.c-1359-}\n--\ndrivers/s390/crypto/ap_bus.c=1363=static ssize_t ap_usage_domain_mask_show(const struct bus_type bus, char buf)\ndrivers/s390/crypto/ap_bus.c-1364-{\ndrivers/s390/crypto/ap_bus.c:1365:\tif (!ap_qci_info-\u003eflags)\t/ QCI not supported /\ndrivers/s390/crypto/ap_bus.c-1366-\t\treturn sysfs_emit(buf, \"not supported\\n\");\n--\ndrivers/s390/crypto/ap_bus.c-1368-\treturn sysfs_emit(buf, \"0x%08x%08x%08x%08x%08x%08x%08x%08x\\n\",\ndrivers/s390/crypto/ap_bus.c:1369:\t\t\t ap_qci_info-\u003eaqm[0], ap_qci_info-\u003eaqm[1],\ndrivers/s390/crypto/ap_bus.c:1370:\t\t\t ap_qci_info-\u003eaqm[2], ap_qci_info-\u003eaqm[3],\ndrivers/s390/crypto/ap_bus.c:1371:\t\t\t ap_qci_info-\u003eaqm[4], ap_qci_info-\u003eaqm[5],\ndrivers/s390/crypto/ap_bus.c:1372:\t\t\t ap_qci_info-\u003eaqm[6], ap_qci_info-\u003eaqm[7]);\ndrivers/s390/crypto/ap_bus.c-1373-}\n--\ndrivers/s390/crypto/ap_bus.c=1377=static ssize_t ap_adapter_mask_show(const struct bus_type bus, char buf)\ndrivers/s390/crypto/ap_bus.c-1378-{\ndrivers/s390/crypto/ap_bus.c:1379:\tif (!ap_qci_info-\u003eflags)\t/ QCI not supported /\ndrivers/s390/crypto/ap_bus.c-1380-\t\treturn sysfs_emit(buf, \"not supported\\n\");\n--\ndrivers/s390/crypto/ap_bus.c-1382-\treturn sysfs_emit(buf, \"0x%08x%08x%08x%08x%08x%08x%08x%08x\\n\",\ndrivers/s390/crypto/ap_bus.c:1383:\t\t\t ap_qci_info-\u003eapm[0], ap_qci_info-\u003eapm[1],\ndrivers/s390/crypto/ap_bus.c:1384:\t\t\t ap_qci_info-\u003eapm[2], ap_qci_info-\u003eapm[3],\ndrivers/s390/crypto/ap_bus.c:1385:\t\t\t ap_qci_info-\u003eapm[4], ap_qci_info-\u003eapm[5],\ndrivers/s390/crypto/ap_bus.c:1386:\t\t\t ap_qci_info-\u003eapm[6], ap_qci_info-\u003eapm[7]);\ndrivers/s390/crypto/ap_bus.c-1387-}\n--\ndrivers/s390/crypto/ap_bus.c=1747=static ssize_t features_show(const struct bus_type bus, char buf)\n--\ndrivers/s390/crypto/ap_bus.c-1750-\ndrivers/s390/crypto/ap_bus.c:1751:\tif (!ap_qci_info-\u003eflags)\t/ QCI not supported /\ndrivers/s390/crypto/ap_bus.c-1752-\t\treturn sysfs_emit(buf, \"-\\n\");\ndrivers/s390/crypto/ap_bus.c-1753-\ndrivers/s390/crypto/ap_bus.c:1754:\tif (ap_qci_info-\u003eapsc)\ndrivers/s390/crypto/ap_bus.c-1755-\t\tn += sysfs_emit_at(buf, n, \"APSC \");\ndrivers/s390/crypto/ap_bus.c:1756:\tif (ap_qci_info-\u003eapxa)\ndrivers/s390/crypto/ap_bus.c-1757-\t\tn += sysfs_emit_at(buf, n, \"APXA \");\ndrivers/s390/crypto/ap_bus.c:1758:\tif (ap_qci_info-\u003eqact)\ndrivers/s390/crypto/ap_bus.c-1759-\t\tn += sysfs_emit_at(buf, n, \"QACT \");\ndrivers/s390/crypto/ap_bus.c:1760:\tif (ap_qci_info-\u003erc8a)\ndrivers/s390/crypto/ap_bus.c-1761-\t\tn += sysfs_emit_at(buf, n, \"RC8A \");\ndrivers/s390/crypto/ap_bus.c:1762:\tif (ap_qci_info-\u003eapsb)\ndrivers/s390/crypto/ap_bus.c-1763-\t\tn += sysfs_emit_at(buf, n, \"APSB \");\n--\ndrivers/s390/crypto/ap_bus.c=1923=static int __drv_notify_config_changed(struct device_driver drv, void data)\n--\ndrivers/s390/crypto/ap_bus.c-1928-\t\tif (ap_drv-\u003eon_config_changed)\ndrivers/s390/crypto/ap_bus.c:1929:\t\t\tap_drv-\u003eon_config_changed(ap_qci_info, ap_qci_info_old);\ndrivers/s390/crypto/ap_bus.c-1930-\t\tmodule_put(drv-\u003eowner);\n--\ndrivers/s390/crypto/ap_bus.c=1944=static int __drv_notify_scan_complete(struct device_driver drv, void data)\n--\ndrivers/s390/crypto/ap_bus.c-1949-\t\tif (ap_drv-\u003eon_scan_complete)\ndrivers/s390/crypto/ap_bus.c:1950:\t\t\tap_drv-\u003eon_scan_complete(ap_qci_info,\ndrivers/s390/crypto/ap_bus.c:1951:\t\t\t\t\t\t ap_qci_info_old);\ndrivers/s390/crypto/ap_bus.c-1952-\t\tmodule_put(drv-\u003eowner);\n--\ndrivers/s390/crypto/ap_bus.c=2311=static bool ap_get_configuration(void)\ndrivers/s390/crypto/ap_bus.c-2312-{\ndrivers/s390/crypto/ap_bus.c:2313:\tif (!ap_qci_info-\u003eflags)\t/ QCI not supported /\ndrivers/s390/crypto/ap_bus.c-2314-\t\treturn false;\ndrivers/s390/crypto/ap_bus.c-2315-\ndrivers/s390/crypto/ap_bus.c:2316:\tmemcpy(ap_qci_info_old, ap_qci_info, sizeof(ap_qci_info));\ndrivers/s390/crypto/ap_bus.c:2317:\tap_qci(ap_qci_info);\ndrivers/s390/crypto/ap_bus.c-2318-\ndrivers/s390/crypto/ap_bus.c:2319:\treturn memcmp(ap_qci_info, ap_qci_info_old,\ndrivers/s390/crypto/ap_bus.c-2320-\t\t sizeof(struct ap_config_info)) != 0;\n--\ndrivers/s390/crypto/ap_bus.c=2329=static bool ap_config_has_new_aps(void)\n--\ndrivers/s390/crypto/ap_bus.c-2333-\ndrivers/s390/crypto/ap_bus.c:2334:\tif (!ap_qci_info-\u003eflags)\ndrivers/s390/crypto/ap_bus.c-2335-\t\treturn false;\ndrivers/s390/crypto/ap_bus.c-2336-\ndrivers/s390/crypto/ap_bus.c:2337:\tbitmap_andnot(m, (unsigned long )ap_qci_info-\u003eapm,\ndrivers/s390/crypto/ap_bus.c:2338:\t\t (unsigned long )ap_qci_info_old-\u003eapm, AP_DEVICES);\ndrivers/s390/crypto/ap_bus.c-2339-\tif (!bitmap_empty(m, AP_DEVICES))\n--\ndrivers/s390/crypto/ap_bus.c=2351=static bool ap_config_has_new_doms(void)\n--\ndrivers/s390/crypto/ap_bus.c-2354-\ndrivers/s390/crypto/ap_bus.c:2355:\tif (!ap_qci_info-\u003eflags)\ndrivers/s390/crypto/ap_bus.c-2356-\t\treturn false;\ndrivers/s390/crypto/ap_bus.c-2357-\ndrivers/s390/crypto/ap_bus.c:2358:\tbitmap_andnot(m, (unsigned long )ap_qci_info-\u003eaqm,\ndrivers/s390/crypto/ap_bus.c:2359:\t\t (unsigned long )ap_qci_info_old-\u003eaqm, AP_DOMAINS);\ndrivers/s390/crypto/ap_bus.c-2360-\tif (!bitmap_empty(m, AP_DOMAINS))\n--\ndrivers/s390/crypto/vfio_ap_drv.c=86=static int vfio_ap_matrix_dev_create(void)\n--\ndrivers/s390/crypto/vfio_ap_drv.c-106-\tif (test_facility(12)) {\ndrivers/s390/crypto/vfio_ap_drv.c:107:\t\tret = ap_qci(\u0026matrix_dev-\u003einfo);\ndrivers/s390/crypto/vfio_ap_drv.c-108-\t\tif (ret)\n" }
13/2	2026/08/06 21:15	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 24998 output: 18 thoughts: 299 Thoughts: My Analysis of VFIO AP Device Creation Okay, so I'm looking at this `vfio_ap_matrix_dev_create` function, specifically that `test_facility(12)` check. My initial thought was that if facility 12 wasn't present, the whole thing would error out. But hang on, it doesn't! It just skips the `ap_qci` call. And since the `matrix_dev->info` struct was `kzalloc_obj`'d, it'll just be zeroed out. That means the device creation succeeds even without the facility. So, the matrix device gets registered, even in this "partial" state. Interesting. Now, can we actually create an mdev on top of this? I need to check the `vfio_ap_mdev_probe` and `vfio_ap_mdev_init_dev` functions to see what happens there. My immediate thought is, QEMU might not be fully emulating the AP instructions by default, but KVM can pass them through. That's the difference. And wait, isn't syzkaller often run with KVM on s390x? Yes, it is! So it should have the capability to interact with these devices, at least in a passthrough configuration. Which brings me to the core question: does syzkaller have existing descriptions or fuzzing coverage for `vfio_ap`? I need to check the syzkaller code base to see if there are any definitions or test cases related to the VFIO AP subsystem. That's the key to exploiting any vulnerabilities here. I'm going to find out.
14/2	2026/08/06 21:15	tool	grepper	0m Args: { "Expression": "vfio_ap" } Results: { "Output": "\nFull output is too long, showing 500 out of 1503 lines.\nUse more precise expression if possible.\n\nDocumentation/arch/s390/vfio-ap-locking.rst=6=This document describes the locks that are pertinent to the secure operation\nDocumentation/arch/s390/vfio-ap-locking.rst:7:of the vfio_ap device driver. Throughout this document, the following variables\nDocumentation/arch/s390/vfio-ap-locking.rst-8-will be used to denote instances of the structures herein described:\n--\nDocumentation/arch/s390/vfio-ap-locking.rst-15-\nDocumentation/arch/s390/vfio-ap-locking.rst:16:The Matrix Devices Lock (drivers/s390/crypto/vfio_ap_private.h)\nDocumentation/arch/s390/vfio-ap-locking.rst-17----------------------------------------------------------------\n--\nDocumentation/arch/s390/vfio-ap-locking.rst=32=or using the data from a field contained within a matrix_mdev instance\nDocumentation/arch/s390/vfio-ap-locking.rst:33:representing one of the vfio_ap device driver's mediated devices.\nDocumentation/arch/s390/vfio-ap-locking.rst-34-\n--\nDocumentation/arch/s390/vfio-ap-locking.rst=46=The KVM Lock (kvm-\u003elock) controls access to the state data for a KVM guest. This\nDocumentation/arch/s390/vfio-ap-locking.rst:47:lock must be held by the vfio_ap device driver while one or more AP adapters,\nDocumentation/arch/s390/vfio-ap-locking.rst-48-domains or control domains are being plugged into or unplugged from the guest.\n--\nDocumentation/arch/s390/vfio-ap-locking.rst=52=been attached to the KVM guest.\nDocumentation/arch/s390/vfio-ap-locking.rst-53-\nDocumentation/arch/s390/vfio-ap-locking.rst:54:The Guests Lock (drivers/s390/crypto/vfio_ap_private.h)\nDocumentation/arch/s390/vfio-ap-locking.rst-55------------------------------------------------------------\n--\nDocumentation/arch/s390/vfio-ap-locking.rst=69=KVM guest. This lock must be held:\nDocumentation/arch/s390/vfio-ap-locking.rst-70-\nDocumentation/arch/s390/vfio-ap-locking.rst:71:1. To control access to the KVM pointer (matrix_mdev-\u003ekvm) while the vfio_ap\nDocumentation/arch/s390/vfio-ap-locking.rst-72- device driver is using it to plug/unplug AP devices passed through to the KVM\n--\nDocumentation/arch/s390/vfio-ap-locking.rst-79-\nDocumentation/arch/s390/vfio-ap-locking.rst:80: For example, when a queue device is removed from the vfio_ap device driver,\nDocumentation/arch/s390/vfio-ap-locking.rst-81- if the adapter is passed through to a KVM guest, it will have to be\n--\nDocumentation/arch/s390/vfio-ap.rst=188=The design introduces three new objects:\n--\nDocumentation/arch/s390/vfio-ap.rst-190-1. AP matrix device\nDocumentation/arch/s390/vfio-ap.rst:191:2. VFIO AP device driver (vfio_ap.ko)\nDocumentation/arch/s390/vfio-ap.rst-192-3. VFIO AP mediated pass-through device\n--\nDocumentation/arch/s390/vfio-ap.rst=194=The VFIO AP device driver\nDocumentation/arch/s390/vfio-ap.rst-195--------------------------\nDocumentation/arch/s390/vfio-ap.rst:196:The VFIO AP (vfio_ap) device driver serves the following purposes:\nDocumentation/arch/s390/vfio-ap.rst-197-\n--\nDocumentation/arch/s390/vfio-ap.rst-199-\nDocumentation/arch/s390/vfio-ap.rst:200:2. Sets up the VFIO mediated device interfaces to manage a vfio_ap mediated\nDocumentation/arch/s390/vfio-ap.rst-201- device and creates the sysfs interfaces for assigning adapters, usage\n--\nDocumentation/arch/s390/vfio-ap.rst=211=reserved::\n--\nDocumentation/arch/s390/vfio-ap.rst-231- \| \| \| \|\nDocumentation/arch/s390/vfio-ap.rst:232: \| ap_bus +--------------------- \u003e vfio_ap driver \|\nDocumentation/arch/s390/vfio-ap.rst-233- \| \| 8 probe \| \|\n--\nDocumentation/arch/s390/vfio-ap.rst-243-\t \| \| \| \|\nDocumentation/arch/s390/vfio-ap.rst:244:\t \| \| 9 create vfio_ap-passthrough \| \|\nDocumentation/arch/s390/vfio-ap.rst-245-\t \| +------------------------------+ \|\n--\nDocumentation/arch/s390/vfio-ap.rst=249=The process for reserving an AP queue for use by a KVM guest is:\nDocumentation/arch/s390/vfio-ap.rst-250-\nDocumentation/arch/s390/vfio-ap.rst:251:1. The administrator loads the vfio_ap device driver\nDocumentation/arch/s390/vfio-ap.rst-252-2. The vfio-ap driver during its initialization will register a single 'matrix'\nDocumentation/arch/s390/vfio-ap.rst-253- device with the device core. This will serve as the parent device for\nDocumentation/arch/s390/vfio-ap.rst:254: all vfio_ap mediated devices used to configure an AP matrix for a guest.\nDocumentation/arch/s390/vfio-ap.rst:255:3. The /sys/devices/vfio_ap/matrix device is created by the device core\nDocumentation/arch/s390/vfio-ap.rst:256:4. The vfio_ap device driver will register with the AP bus for AP queue devices\nDocumentation/arch/s390/vfio-ap.rst:257: of type 10 and higher (CEX4 and newer). The driver will provide the vfio_ap\nDocumentation/arch/s390/vfio-ap.rst-258- driver's probe and remove callback interfaces. Devices older than CEX4 queues\n--\nDocumentation/arch/s390/vfio-ap.rst-262- systems around on which to test.\nDocumentation/arch/s390/vfio-ap.rst:263:5. The AP bus registers the vfio_ap device driver with the device core\nDocumentation/arch/s390/vfio-ap.rst-264-6. The administrator edits the AP adapter and queue masks to reserve AP queues\nDocumentation/arch/s390/vfio-ap.rst:265: for use by the vfio_ap device driver.\nDocumentation/arch/s390/vfio-ap.rst:266:7. The AP bus removes the AP queues reserved for the vfio_ap driver from the\nDocumentation/arch/s390/vfio-ap.rst-267- default zcrypt cex4queue driver.\nDocumentation/arch/s390/vfio-ap.rst:268:8. The AP bus probes the vfio_ap device driver to bind the queues reserved for\nDocumentation/arch/s390/vfio-ap.rst-269- it.\nDocumentation/arch/s390/vfio-ap.rst:270:9. The administrator creates a passthrough type vfio_ap mediated device to be\nDocumentation/arch/s390/vfio-ap.rst-271- used by a guest\n--\nDocumentation/arch/s390/vfio-ap.rst=278=device core driver to:\nDocumentation/arch/s390/vfio-ap.rst-279-\nDocumentation/arch/s390/vfio-ap.rst:280:* Register an AP mediated bus driver to add a vfio_ap mediated device to and\nDocumentation/arch/s390/vfio-ap.rst-281- remove it from a VFIO group.\nDocumentation/arch/s390/vfio-ap.rst:282:* Create and destroy a vfio_ap mediated device\nDocumentation/arch/s390/vfio-ap.rst:283:* Add a vfio_ap mediated device to and remove it from the AP mediated bus driver\nDocumentation/arch/s390/vfio-ap.rst:284:* Add a vfio_ap mediated device to and remove it from an IOMMU group\nDocumentation/arch/s390/vfio-ap.rst-285-\n--\nDocumentation/arch/s390/vfio-ap.rst=287=of the VFIO AP mediated device driver::\n--\nDocumentation/arch/s390/vfio-ap.rst-301- \| \|Physical \| +\u003c-----------------------+ \|\nDocumentation/arch/s390/vfio-ap.rst:302: \| \| device \| \| \| vfio_ap.ko \|\u003c-\u003e matrix\nDocumentation/arch/s390/vfio-ap.rst-303- \| \|interface\| +-----------------------\u003e+ \| device\n--\nDocumentation/arch/s390/vfio-ap.rst-306-\nDocumentation/arch/s390/vfio-ap.rst:307:During initialization of the vfio_ap module, the matrix device is registered\nDocumentation/arch/s390/vfio-ap.rst-308-with an 'mdev_parent_ops' structure that provides the sysfs attribute\n--\nDocumentation/arch/s390/vfio-ap.rst=310=matrix device.\n--\nDocumentation/arch/s390/vfio-ap.rst-326-\nDocumentation/arch/s390/vfio-ap.rst:327: /sys/devices/vfio_ap/matrix/mdev_supported_types/vfio_ap-passthrough\nDocumentation/arch/s390/vfio-ap.rst-328-\n--\nDocumentation/arch/s390/vfio-ap.rst-343-\t* available_instances:\nDocumentation/arch/s390/vfio-ap.rst:344:\t the number of vfio_ap mediated passthrough devices\nDocumentation/arch/s390/vfio-ap.rst-345-\t that can be created\n--\nDocumentation/arch/s390/vfio-ap.rst-351- framework, the sysfs attribute files identified in the 'mdev_attr_groups'\nDocumentation/arch/s390/vfio-ap.rst:352: structure will be created in the vfio_ap mediated device's directory. The\nDocumentation/arch/s390/vfio-ap.rst:353: sysfs attributes for a vfio_ap mediated device are:\nDocumentation/arch/s390/vfio-ap.rst-354-\n--\nDocumentation/arch/s390/vfio-ap.rst-356- Write-only attributes for assigning/unassigning an AP adapter to/from the\nDocumentation/arch/s390/vfio-ap.rst:357: vfio_ap mediated device. To assign/unassign an adapter, the APID of the\nDocumentation/arch/s390/vfio-ap.rst-358- adapter is echoed into the respective attribute file.\n--\nDocumentation/arch/s390/vfio-ap.rst-360- Write-only attributes for assigning/unassigning an AP usage domain to/from\nDocumentation/arch/s390/vfio-ap.rst:361: the vfio_ap mediated device. To assign/unassign a domain, the domain\nDocumentation/arch/s390/vfio-ap.rst-362- number of the usage domain is echoed into the respective attribute\n--\nDocumentation/arch/s390/vfio-ap.rst-365- A read-only file for displaying the APQNs derived from the Cartesian\nDocumentation/arch/s390/vfio-ap.rst:366: product of the adapter and domain numbers assigned to the vfio_ap mediated\nDocumentation/arch/s390/vfio-ap.rst-367- device.\n--\nDocumentation/arch/s390/vfio-ap.rst-371- fields respectively of the KVM guest's CRYCB. This may differ from the\nDocumentation/arch/s390/vfio-ap.rst:372: the APQNs assigned to the vfio_ap mediated device if any APQN does not\nDocumentation/arch/s390/vfio-ap.rst:373: reference a queue device bound to the vfio_ap device driver (i.e., the\nDocumentation/arch/s390/vfio-ap.rst-374- queue is not in the host's AP configuration).\n--\nDocumentation/arch/s390/vfio-ap.rst-376- Write-only attributes for assigning/unassigning an AP control domain\nDocumentation/arch/s390/vfio-ap.rst:377: to/from the vfio_ap mediated device. To assign/unassign a control domain,\nDocumentation/arch/s390/vfio-ap.rst-378- the ID of the domain to be assigned/unassigned is echoed into the\n--\nDocumentation/arch/s390/vfio-ap.rst-381- A read-only file for displaying the control domain numbers assigned to the\nDocumentation/arch/s390/vfio-ap.rst:382: vfio_ap mediated device.\nDocumentation/arch/s390/vfio-ap.rst-383- ap_config:\nDocumentation/arch/s390/vfio-ap.rst-384- A read/write file that, when written to, allows all three of the\nDocumentation/arch/s390/vfio-ap.rst:385: vfio_ap mediated device's ap matrix masks to be replaced in one shot.\nDocumentation/arch/s390/vfio-ap.rst-386- Three masks are given, one for adapters, one for domains, and one for\n--\nDocumentation/arch/s390/vfio-ap.rst-416- create:\nDocumentation/arch/s390/vfio-ap.rst:417: allocates the ap_matrix_mdev structure used by the vfio_ap driver to:\nDocumentation/arch/s390/vfio-ap.rst-418-\n--\nDocumentation/arch/s390/vfio-ap.rst-424- referencing queue devices that do not exist, or are not bound to the\nDocumentation/arch/s390/vfio-ap.rst:425: vfio_ap device driver.\nDocumentation/arch/s390/vfio-ap.rst-426-\nDocumentation/arch/s390/vfio-ap.rst-427- remove:\nDocumentation/arch/s390/vfio-ap.rst:428: deallocates the vfio_ap mediated device's ap_matrix_mdev structure.\nDocumentation/arch/s390/vfio-ap.rst-429- This will be allowed only if a running guest is not using the mdev.\n--\nDocumentation/arch/s390/vfio-ap.rst-437- and configures the guest's access to the AP matrix defined via the\nDocumentation/arch/s390/vfio-ap.rst:438: vfio_ap mediated device's sysfs attribute files.\nDocumentation/arch/s390/vfio-ap.rst-439-\n--\nDocumentation/arch/s390/vfio-ap.rst=451=configured via its APCB by:\n--\nDocumentation/arch/s390/vfio-ap.rst-453-* Setting the bits in the APM corresponding to the APIDs assigned to the\nDocumentation/arch/s390/vfio-ap.rst:454: vfio_ap mediated device via its 'assign_adapter' interface.\nDocumentation/arch/s390/vfio-ap.rst-455-* Setting the bits in the AQM corresponding to the domains assigned to the\nDocumentation/arch/s390/vfio-ap.rst:456: vfio_ap mediated device via its 'assign_domain' interface.\nDocumentation/arch/s390/vfio-ap.rst-457-* Setting the bits in the ADM corresponding to the domain dIDs assigned to the\nDocumentation/arch/s390/vfio-ap.rst:458: vfio_ap mediated device via its 'assign_control_domains' interface.\nDocumentation/arch/s390/vfio-ap.rst-459-\n--\nDocumentation/arch/s390/vfio-ap.rst=461=is not bound to the device driver facilitating its pass-through. Consequently,\nDocumentation/arch/s390/vfio-ap.rst:462:an APQN that does not reference a queue device bound to the vfio_ap device\nDocumentation/arch/s390/vfio-ap.rst-463-driver will not be assigned to a KVM guest's matrix. The AP architecture,\nDocumentation/arch/s390/vfio-ap.rst=464=however, does not provide a means to filter individual APQNs from the guest's\nDocumentation/arch/s390/vfio-ap.rst:465:matrix, so the adapters, domains and control domains assigned to vfio_ap\nDocumentation/arch/s390/vfio-ap.rst-466-mediated device via its sysfs 'assign_adapter', 'assign_domain' and\n--\nDocumentation/arch/s390/vfio-ap.rst=468=configuration to a guest:\n--\nDocumentation/arch/s390/vfio-ap.rst-474-* Each APQN derived from the Cartesian product of the APIDs and APQIs assigned\nDocumentation/arch/s390/vfio-ap.rst:475: to the vfio_ap mdev is examined and if any one of them does not reference a\nDocumentation/arch/s390/vfio-ap.rst:476: queue device bound to the vfio_ap device driver, the adapter will not be\nDocumentation/arch/s390/vfio-ap.rst-477- plugged into the guest (i.e., the bit corresponding to its APID will not be\n--\nDocumentation/arch/s390/vfio-ap.rst=563=These are the steps:\nDocumentation/arch/s390/vfio-ap.rst-564-\nDocumentation/arch/s390/vfio-ap.rst:565:1. Install the vfio_ap module on the linux host. The dependency chain for the\nDocumentation/arch/s390/vfio-ap.rst:566: vfio_ap module is:\nDocumentation/arch/s390/vfio-ap.rst-567- * iommu\n--\nDocumentation/arch/s390/vfio-ap.rst-574-\nDocumentation/arch/s390/vfio-ap.rst:575: To build the vfio_ap module, the kernel build must be configured with the\nDocumentation/arch/s390/vfio-ap.rst-576- following Kconfig elements selected:\n--\nDocumentation/arch/s390/vfio-ap.rst-582-\nDocumentation/arch/s390/vfio-ap.rst:583: If using make menuconfig select the following to build the vfio_ap module::\nDocumentation/arch/s390/vfio-ap.rst-584-\n--\nDocumentation/arch/s390/vfio-ap.rst-597- queue device drivers. All remaining APQNs are available for use by\nDocumentation/arch/s390/vfio-ap.rst:598: any other device driver. The vfio_ap device driver is currently the only\nDocumentation/arch/s390/vfio-ap.rst-599- non-default device driver. The location of the sysfs files containing the\n--\nDocumentation/arch/s390/vfio-ap.rst-618- All other APQNs are available to the non-default device drivers such as the\nDocumentation/arch/s390/vfio-ap.rst:619: vfio_ap driver.\nDocumentation/arch/s390/vfio-ap.rst-620-\n--\nDocumentation/arch/s390/vfio-ap.rst-646- match is detected, only the default AP queue device drivers will be probed;\nDocumentation/arch/s390/vfio-ap.rst:647: otherwise, the vfio_ap device driver will be probed.\nDocumentation/arch/s390/vfio-ap.rst-648-\n--\nDocumentation/arch/s390/vfio-ap.rst-708- Note:\nDocumentation/arch/s390/vfio-ap.rst:709: Changing a mask such that one or more APQNs will be taken from a vfio_ap\nDocumentation/arch/s390/vfio-ap.rst-710- mediated device (see below) will fail with an error (EBUSY). A message\n--\nDocumentation/arch/s390/vfio-ap.rst-712- command. The output identifies each APQN flagged as 'in use' and identifies\nDocumentation/arch/s390/vfio-ap.rst:713: the vfio_ap mediated device to which it is assigned; for example:\nDocumentation/arch/s390/vfio-ap.rst-714-\n--\nDocumentation/arch/s390/vfio-ap.rst=718=Securing the APQNs for our example\n--\nDocumentation/arch/s390/vfio-ap.rst-720- To secure the AP queues 05.0004, 05.0047, 05.00ab, 05.00ff, 06.0004, 06.0047,\nDocumentation/arch/s390/vfio-ap.rst:721: 06.00ab, and 06.00ff for use by the vfio_ap device driver, the corresponding\nDocumentation/arch/s390/vfio-ap.rst-722- APQNs can be removed from the default masks using either of the following\n--\nDocumentation/arch/s390/vfio-ap.rst-737- This will result in AP queues 05.0004, 05.0047, 05.00ab, 05.00ff, 06.0004,\nDocumentation/arch/s390/vfio-ap.rst:738: 06.0047, 06.00ab, and 06.00ff getting bound to the vfio_ap device driver. The\nDocumentation/arch/s390/vfio-ap.rst:739: sysfs directory for the vfio_ap device driver will now contain symbolic links\nDocumentation/arch/s390/vfio-ap.rst-740- to the AP queue devices bound to it::\n--\nDocumentation/arch/s390/vfio-ap.rst-743- ... [drivers]\nDocumentation/arch/s390/vfio-ap.rst:744: ...... [vfio_ap]\nDocumentation/arch/s390/vfio-ap.rst-745- ......... [05.0004]\n--\nDocumentation/arch/s390/vfio-ap.rst-754- Keep in mind that only type 10 and newer adapters (i.e., CEX4 and later)\nDocumentation/arch/s390/vfio-ap.rst:755: can be bound to the vfio_ap device driver. The reason for this is to\nDocumentation/arch/s390/vfio-ap.rst-756- simplify the implementation by not needlessly complicating the design by\n--\nDocumentation/arch/s390/vfio-ap.rst-760- The administrator, therefore, must take care to secure only AP queues that\nDocumentation/arch/s390/vfio-ap.rst:761: can be bound to the vfio_ap device driver. The device type for a given AP\nDocumentation/arch/s390/vfio-ap.rst-762- queue device can be read from the parent card's sysfs directory. For example,\n--\nDocumentation/arch/s390/vfio-ap.rst-767- The hwtype must be 10 or higher (CEX4 or newer) in order to be bound to the\nDocumentation/arch/s390/vfio-ap.rst:768: vfio_ap device driver.\nDocumentation/arch/s390/vfio-ap.rst-769-\nDocumentation/arch/s390/vfio-ap.rst-770-3. Create the mediated devices needed to configure the AP matrixes for the\nDocumentation/arch/s390/vfio-ap.rst:771: three guests and to provide an interface to the vfio_ap driver for\nDocumentation/arch/s390/vfio-ap.rst-772- use by the guests::\nDocumentation/arch/s390/vfio-ap.rst-773-\nDocumentation/arch/s390/vfio-ap.rst:774: /sys/devices/vfio_ap/matrix/\nDocumentation/arch/s390/vfio-ap.rst-775- --- [mdev_supported_types]\nDocumentation/arch/s390/vfio-ap.rst:776: ------ [vfio_ap-passthrough] (passthrough vfio_ap mediated device type)\nDocumentation/arch/s390/vfio-ap.rst-777- --------- create\n--\nDocumentation/arch/s390/vfio-ap.rst-795-\nDocumentation/arch/s390/vfio-ap.rst:796: /sys/devices/vfio_ap/matrix/\nDocumentation/arch/s390/vfio-ap.rst-797- --- [mdev_supported_types]\nDocumentation/arch/s390/vfio-ap.rst:798: ------ [vfio_ap-passthrough]\nDocumentation/arch/s390/vfio-ap.rst-799- --------- [devices]\n--\nDocumentation/arch/s390/vfio-ap.rst-826-\nDocumentation/arch/s390/vfio-ap.rst:827: Note ****: The vfio_ap mdevs do not persist across reboots unless the\nDocumentation/arch/s390/vfio-ap.rst-828- mdevctl tool is used to create and persist them.\n--\nDocumentation/arch/s390/vfio-ap.rst-879-\nDocumentation/arch/s390/vfio-ap.rst:880: - Must only be available to the vfio_ap device driver as specified in the\nDocumentation/arch/s390/vfio-ap.rst-881- sysfs /sys/bus/ap/apmask and /sys/bus/ap/aqmask attribute files. If even\n--\nDocumentation/arch/s390/vfio-ap.rst-884-\nDocumentation/arch/s390/vfio-ap.rst:885: - Must NOT be assigned to another vfio_ap mediated device. If even one APQN\nDocumentation/arch/s390/vfio-ap.rst:886: is assigned to another vfio_ap mediated device, the operation will\nDocumentation/arch/s390/vfio-ap.rst-887- terminate with an error (EBUSY).\n--\nDocumentation/arch/s390/vfio-ap.rst-905-\nDocumentation/arch/s390/vfio-ap.rst:906: - Must only be available to the vfio_ap device driver as specified in the\nDocumentation/arch/s390/vfio-ap.rst-907- sysfs /sys/bus/ap/apmask and /sys/bus/ap/aqmask attribute files. If even\n--\nDocumentation/arch/s390/vfio-ap.rst-910-\nDocumentation/arch/s390/vfio-ap.rst:911: - Must NOT be assigned to another vfio_ap mediated device. If even one APQN\nDocumentation/arch/s390/vfio-ap.rst:912: is assigned to another vfio_ap mediated device, the operation will\nDocumentation/arch/s390/vfio-ap.rst-913- terminate with an error (EBUSY).\n--\nDocumentation/arch/s390/vfio-ap.rst-928- /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on,apqi=on \\\nDocumentation/arch/s390/vfio-ap.rst:929:\t-device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid1 ...\nDocumentation/arch/s390/vfio-ap.rst-930-\n--\nDocumentation/arch/s390/vfio-ap.rst-933- /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on,apqi=on \\\nDocumentation/arch/s390/vfio-ap.rst:934:\t-device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid2 ...\nDocumentation/arch/s390/vfio-ap.rst-935-\n--\nDocumentation/arch/s390/vfio-ap.rst-938- /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on,apqi=on \\\nDocumentation/arch/s390/vfio-ap.rst:939:\t-device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid3 ...\nDocumentation/arch/s390/vfio-ap.rst-940-\nDocumentation/arch/s390/vfio-ap.rst:941:When the guest is shut down, the vfio_ap mediated devices may be removed.\nDocumentation/arch/s390/vfio-ap.rst-942-\nDocumentation/arch/s390/vfio-ap.rst:943:Using our example again, to remove the vfio_ap mediated device $uuid1::\nDocumentation/arch/s390/vfio-ap.rst-944-\nDocumentation/arch/s390/vfio-ap.rst:945: /sys/devices/vfio_ap/matrix/\nDocumentation/arch/s390/vfio-ap.rst-946- --- [mdev_supported_types]\nDocumentation/arch/s390/vfio-ap.rst:947: ------ [vfio_ap-passthrough]\nDocumentation/arch/s390/vfio-ap.rst-948- --------- [devices]\n--\nDocumentation/arch/s390/vfio-ap.rst=958=all of the steps starting with step 3 will have to be performed again. Note\nDocumentation/arch/s390/vfio-ap.rst:959:that the remove will fail if a guest using the vfio_ap mdev is still running.\nDocumentation/arch/s390/vfio-ap.rst-960-\nDocumentation/arch/s390/vfio-ap.rst:961:It is not necessary to remove a vfio_ap mdev, but one may want to\nDocumentation/arch/s390/vfio-ap.rst-962-remove it if no guest will use it during the remaining lifetime of the linux\nDocumentation/arch/s390/vfio-ap.rst:963:host. If the vfio_ap mdev is removed, one may want to also reconfigure\nDocumentation/arch/s390/vfio-ap.rst-964-the pool of adapters and queues reserved for use by the default drivers.\n--\nDocumentation/arch/s390/vfio-ap.rst=968=An adapter, domain or control domain may be hot plugged into a running KVM\nDocumentation/arch/s390/vfio-ap.rst:969:guest by assigning it to the vfio_ap mediated device being used by the guest if\nDocumentation/arch/s390/vfio-ap.rst-970-the following conditions are met:\n--\nDocumentation/arch/s390/vfio-ap.rst-976- adapter being assigned and the APQIs of the domains assigned must reference a\nDocumentation/arch/s390/vfio-ap.rst:977: queue device bound to the vfio_ap device driver.\nDocumentation/arch/s390/vfio-ap.rst-978-\n--\nDocumentation/arch/s390/vfio-ap.rst-980- comprised of the APQI of the domain being assigned and the APIDs of the\nDocumentation/arch/s390/vfio-ap.rst:981: adapters assigned must reference a queue device bound to the vfio_ap device\nDocumentation/arch/s390/vfio-ap.rst-982- driver.\n--\nDocumentation/arch/s390/vfio-ap.rst=984=An adapter, domain or control domain may be hot unplugged from a running KVM\nDocumentation/arch/s390/vfio-ap.rst:985:guest by unassigning it from the vfio_ap mediated device being used by the\nDocumentation/arch/s390/vfio-ap.rst-986-guest.\n--\nDocumentation/arch/s390/vfio-ap.rst=990=Over-provisioning is defined herein as the assignment of adapters or domains to\nDocumentation/arch/s390/vfio-ap.rst:991:a vfio_ap mediated device that do not reference AP devices in the host's AP\nDocumentation/arch/s390/vfio-ap.rst-992-configuration. The idea here is that when the adapter or domain becomes\nDocumentation/arch/s390/vfio-ap.rst=993=available, it will be automatically hot-plugged into the KVM guest using\nDocumentation/arch/s390/vfio-ap.rst:994:the vfio_ap mediated device to which it is assigned as long as each new APQN\nDocumentation/arch/s390/vfio-ap.rst:995:resulting from plugging it in references a queue device bound to the vfio_ap\nDocumentation/arch/s390/vfio-ap.rst-996-device driver.\n--\nDocumentation/arch/s390/vfio-ap.rst=998=Driver Features\nDocumentation/arch/s390/vfio-ap.rst-999-===============\nDocumentation/arch/s390/vfio-ap.rst:1000:The vfio_ap driver exposes a sysfs file containing supported features.\nDocumentation/arch/s390/vfio-ap.rst-1001-This exists so third party tools (like Libvirt and mdevctl) can query the\n--\nDocumentation/arch/s390/vfio-ap.rst=1031=intervention by a system administrator. Before a KVM guest can be migrated,\nDocumentation/arch/s390/vfio-ap.rst:1032:the vfio_ap mediated device must be removed. Unfortunately, it can not be\nDocumentation/arch/s390/vfio-ap.rst:1033:removed manually (i.e., echo 1 \u003e /sys/devices/vfio_ap/matrix/$UUID/remove) while\nDocumentation/arch/s390/vfio-ap.rst-1034-the mdev is in use by a KVM guest. If the guest is being emulated by QEMU,\nDocumentation/arch/s390/vfio-ap.rst=1035=its mdev can be hot unplugged from the guest in one of two ways:\n--\nDocumentation/arch/s390/vfio-ap.rst-1059-\nDocumentation/arch/s390/vfio-ap.rst:1060: For example, to hot unplug the vfio_ap mediated device identified on the\nDocumentation/arch/s390/vfio-ap.rst-1061- qemu command line with 'id=hostdev0' from the guest named 'my-guest':\n--\nDocumentation/arch/s390/vfio-ap.rst-1066-\nDocumentation/arch/s390/vfio-ap.rst:1067:2. A vfio_ap mediated device can be hot unplugged by attaching the qemu monitor\nDocumentation/arch/s390/vfio-ap.rst-1068- to the guest and using the following qemu monitor command:\n--\nDocumentation/arch/s390/vfio-ap.rst-1071-\nDocumentation/arch/s390/vfio-ap.rst:1072: For example, to hot unplug the vfio_ap mediated device that was specified\nDocumentation/arch/s390/vfio-ap.rst-1073- on the qemu command line with 'id=hostdev0' when the guest was started:\n--\nDocumentation/arch/s390/vfio-ap.rst=1077=After live migration of the KVM guest completes, an AP configuration can be\nDocumentation/arch/s390/vfio-ap.rst:1078:restored to the KVM guest by hot plugging a vfio_ap mediated device on the target\nDocumentation/arch/s390/vfio-ap.rst-1079-system into the guest in one of two ways:\n--\nDocumentation/arch/s390/vfio-ap.rst-1104-\nDocumentation/arch/s390/vfio-ap.rst:1105: For example, to hot plug the vfio_ap mediated device\nDocumentation/arch/s390/vfio-ap.rst-1106- 62177883-f1bb-47f0-914d-32a22e3a8804 into the guest named 'my-guest' with\n--\nDocumentation/arch/s390/vfio-ap.rst-1110- \"device_add vfio-ap,\\\nDocumentation/arch/s390/vfio-ap.rst:1111: sysfsdev=/sys/devices/vfio_ap/matrix/62177883-f1bb-47f0-914d-32a22e3a8804,\\\nDocumentation/arch/s390/vfio-ap.rst-1112- id=hostdev0\"\nDocumentation/arch/s390/vfio-ap.rst-1113-\nDocumentation/arch/s390/vfio-ap.rst:1114:2. A vfio_ap mediated device can be hot plugged by attaching the qemu monitor\nDocumentation/arch/s390/vfio-ap.rst-1115- to the guest and using the following qemu monitor command:\n--\nDocumentation/arch/s390/vfio-ap.rst-1118-\nDocumentation/arch/s390/vfio-ap.rst:1119: For example, to plug the vfio_ap mediated device\nDocumentation/arch/s390/vfio-ap.rst-1120- 62177883-f1bb-47f0-914d-32a22e3a8804 into the guest with the device-id\n--\nDocumentation/arch/s390/vfio-ap.rst-1123- (QEMU) device-add \"vfio-ap,\\\nDocumentation/arch/s390/vfio-ap.rst:1124: sysfsdev=/sys/devices/vfio_ap/matrix/62177883-f1bb-47f0-914d-32a22e3a8804,\\\nDocumentation/arch/s390/vfio-ap.rst-1125- id=hostdev0\"\n--\nMAINTAINERS=23603=F:\tDocumentation/arch/s390/vfio-ap\nMAINTAINERS:23604:F:\tdrivers/s390/crypto/vfio_ap\nMAINTAINERS-23605-\n--\narch/s390/Kconfig=834=config VFIO_AP\n--\narch/s390/Kconfig-845-\t To compile this driver as a module, choose M here: the module\narch/s390/Kconfig:846:\t will be called vfio_ap.\narch/s390/Kconfig-847-\n--\narch/s390/kvm/priv.c=570=bool kvm_s390_is_gpa_in_memslot(struct kvm kvm, gpa_t gpa)\n--\narch/s390/kvm/priv.c-573-}\narch/s390/kvm/priv.c:574:EXPORT_SYMBOL_FOR_MODULES(kvm_s390_is_gpa_in_memslot, \"vfio_ap\");\narch/s390/kvm/priv.c-575-#endif\n--\ndrivers/s390/crypto/Makefile=34=obj-$(CONFIG_PKEY_UV) += pkey-uv.o\n--\ndrivers/s390/crypto/Makefile-36-# adjunct processor matrix\ndrivers/s390/crypto/Makefile:37:vfio_ap-objs := vfio_ap_drv.o vfio_ap_ops.o\ndrivers/s390/crypto/Makefile:38:obj-$(CONFIG_VFIO_AP) += vfio_ap.o\n--\ndrivers/s390/crypto/vfio_ap_debug.h-19-#define VFIO_AP_DBF(...)\t\t\t\t\t\\\ndrivers/s390/crypto/vfio_ap_debug.h:20:\tdebug_sprintf_event(vfio_ap_dbf_info, ##__VA_ARGS__)\ndrivers/s390/crypto/vfio_ap_debug.h-21-#define VFIO_AP_DBF_ERR(...)\t\t\t\t\t\\\ndrivers/s390/crypto/vfio_ap_debug.h:22:\tdebug_sprintf_event(vfio_ap_dbf_info, DBF_ERR, ##__VA_ARGS__)\ndrivers/s390/crypto/vfio_ap_debug.h-23-#define VFIO_AP_DBF_WARN(...)\t\t\t\t\t\\\ndrivers/s390/crypto/vfio_ap_debug.h:24:\tdebug_sprintf_event(vfio_ap_dbf_info, DBF_WARN, ##__VA_ARGS__)\ndrivers/s390/crypto/vfio_ap_debug.h-25-#define VFIO_AP_DBF_INFO(...)\t\t\t\t\t\\\ndrivers/s390/crypto/vfio_ap_debug.h:26:\tdebug_sprintf_event(vfio_ap_dbf_info, DBF_INFO, ##__VA_ARGS__)\ndrivers/s390/crypto/vfio_ap_debug.h-27-#define VFIO_AP_DBF_DBG(...)\t\t\t\t\t\\\ndrivers/s390/crypto/vfio_ap_debug.h:28:\tdebug_sprintf_event(vfio_ap_dbf_info, DBF_DEBUG, ##__VA_ARGS__)\ndrivers/s390/crypto/vfio_ap_debug.h-29-\ndrivers/s390/crypto/vfio_ap_debug.h:30:extern debug_info_t vfio_ap_dbf_info;\ndrivers/s390/crypto/vfio_ap_debug.h-31-\n--\ndrivers/s390/crypto/vfio_ap_drv.c-15-#include \u003casm/facility.h\u003e\ndrivers/s390/crypto/vfio_ap_drv.c:16:#include \"vfio_ap_private.h\"\ndrivers/s390/crypto/vfio_ap_drv.c:17:#include \"vfio_ap_debug.h\"\ndrivers/s390/crypto/vfio_ap_drv.c-18-\ndrivers/s390/crypto/vfio_ap_drv.c:19:#define VFIO_AP_ROOT_NAME \"vfio_ap\"\ndrivers/s390/crypto/vfio_ap_drv.c-20-#define VFIO_AP_DEV_NAME \"matrix\"\n--\ndrivers/s390/crypto/vfio_ap_drv.c=26=struct ap_matrix_dev matrix_dev;\ndrivers/s390/crypto/vfio_ap_drv.c:27:debug_info_t vfio_ap_dbf_info;\ndrivers/s390/crypto/vfio_ap_drv.c-28-\n--\ndrivers/s390/crypto/vfio_ap_drv.c=44=static struct ap_device_id ap_queue_ids[] = {\n--\ndrivers/s390/crypto/vfio_ap_drv.c-57-\ndrivers/s390/crypto/vfio_ap_drv.c:58:static struct ap_driver vfio_ap_drv = {\ndrivers/s390/crypto/vfio_ap_drv.c:59:\t.probe = vfio_ap_mdev_probe_queue,\ndrivers/s390/crypto/vfio_ap_drv.c:60:\t.remove = vfio_ap_mdev_remove_queue,\ndrivers/s390/crypto/vfio_ap_drv.c:61:\t.in_use = vfio_ap_mdev_resource_in_use,\ndrivers/s390/crypto/vfio_ap_drv.c:62:\t.on_config_changed = vfio_ap_on_cfg_changed,\ndrivers/s390/crypto/vfio_ap_drv.c:63:\t.on_scan_complete = vfio_ap_on_scan_complete,\ndrivers/s390/crypto/vfio_ap_drv.c-64-\t.ids = ap_queue_ids,\n--\ndrivers/s390/crypto/vfio_ap_drv.c-66-\ndrivers/s390/crypto/vfio_ap_drv.c:67:static void vfio_ap_matrix_dev_release(struct device dev)\ndrivers/s390/crypto/vfio_ap_drv.c-68-{\n--\ndrivers/s390/crypto/vfio_ap_drv.c=79=static struct device_driver matrix_driver = {\ndrivers/s390/crypto/vfio_ap_drv.c:80:\t.name = \"vfio_ap\",\ndrivers/s390/crypto/vfio_ap_drv.c-81-\t.bus = \u0026matrix_bus,\n--\ndrivers/s390/crypto/vfio_ap_drv.c-85-\ndrivers/s390/crypto/vfio_ap_drv.c:86:static int vfio_ap_matrix_dev_create(void)\ndrivers/s390/crypto/vfio_ap_drv.c-87-{\n--\ndrivers/s390/crypto/vfio_ap_drv.c-118-\tmatrix_dev-\u003edevice.bus = \u0026matrix_bus;\ndrivers/s390/crypto/vfio_ap_drv.c:119:\tmatrix_dev-\u003edevice.release = vfio_ap_matrix_dev_release;\ndrivers/s390/crypto/vfio_ap_drv.c:120:\tmatrix_dev-\u003evfio_ap_drv = \u0026vfio_ap_drv;\ndrivers/s390/crypto/vfio_ap_drv.c-121-\n--\ndrivers/s390/crypto/vfio_ap_drv.c-142-\ndrivers/s390/crypto/vfio_ap_drv.c:143:static void vfio_ap_matrix_dev_destroy(void)\ndrivers/s390/crypto/vfio_ap_drv.c-144-{\n--\ndrivers/s390/crypto/vfio_ap_drv.c-152-\ndrivers/s390/crypto/vfio_ap_drv.c:153:static int __init vfio_ap_dbf_info_init(void)\ndrivers/s390/crypto/vfio_ap_drv.c-154-{\ndrivers/s390/crypto/vfio_ap_drv.c:155:\tvfio_ap_dbf_info = debug_register(\"vfio_ap\", 1, 1,\ndrivers/s390/crypto/vfio_ap_drv.c-156-\t\t\t\t\t DBF_MAX_SPRINTF_ARGS * sizeof(long));\ndrivers/s390/crypto/vfio_ap_drv.c-157-\ndrivers/s390/crypto/vfio_ap_drv.c:158:\tif (!vfio_ap_dbf_info)\ndrivers/s390/crypto/vfio_ap_drv.c-159-\t\treturn -ENOENT;\ndrivers/s390/crypto/vfio_ap_drv.c-160-\ndrivers/s390/crypto/vfio_ap_drv.c:161:\tdebug_register_view(vfio_ap_dbf_info, \u0026debug_sprintf_view);\ndrivers/s390/crypto/vfio_ap_drv.c:162:\tdebug_set_level(vfio_ap_dbf_info, DBF_WARN);\ndrivers/s390/crypto/vfio_ap_drv.c-163-\n--\ndrivers/s390/crypto/vfio_ap_drv.c-166-\ndrivers/s390/crypto/vfio_ap_drv.c:167:static int __init vfio_ap_init(void)\ndrivers/s390/crypto/vfio_ap_drv.c-168-{\n--\ndrivers/s390/crypto/vfio_ap_drv.c-170-\ndrivers/s390/crypto/vfio_ap_drv.c:171:\tret = vfio_ap_dbf_info_init();\ndrivers/s390/crypto/vfio_ap_drv.c-172-\tif (ret)\n--\ndrivers/s390/crypto/vfio_ap_drv.c-178-\ndrivers/s390/crypto/vfio_ap_drv.c:179:\tret = vfio_ap_matrix_dev_create();\ndrivers/s390/crypto/vfio_ap_drv.c-180-\tif (ret)\n--\ndrivers/s390/crypto/vfio_ap_drv.c-182-\ndrivers/s390/crypto/vfio_ap_drv.c:183:\tret = ap_driver_register(\u0026vfio_ap_drv, THIS_MODULE, VFIO_AP_DRV_NAME);\ndrivers/s390/crypto/vfio_ap_drv.c-184-\tif (ret) {\ndrivers/s390/crypto/vfio_ap_drv.c:185:\t\tvfio_ap_matrix_dev_destroy();\ndrivers/s390/crypto/vfio_ap_drv.c-186-\t\treturn ret;\n--\ndrivers/s390/crypto/vfio_ap_drv.c-188-\ndrivers/s390/crypto/vfio_ap_drv.c:189:\tret = vfio_ap_mdev_register();\ndrivers/s390/crypto/vfio_ap_drv.c-190-\tif (ret) {\ndrivers/s390/crypto/vfio_ap_drv.c:191:\t\tap_driver_unregister(\u0026vfio_ap_drv);\ndrivers/s390/crypto/vfio_ap_drv.c:192:\t\tvfio_ap_matrix_dev_destroy();\ndrivers/s390/crypto/vfio_ap_drv.c-193-\n--\ndrivers/s390/crypto/vfio_ap_drv.c-199-\ndrivers/s390/crypto/vfio_ap_drv.c:200:static void __exit vfio_ap_exit(void)\ndrivers/s390/crypto/vfio_ap_drv.c-201-{\ndrivers/s390/crypto/vfio_ap_drv.c:202:\tvfio_ap_mdev_unregister();\ndrivers/s390/crypto/vfio_ap_drv.c:203:\tap_driver_unregister(\u0026vfio_ap_drv);\ndrivers/s390/crypto/vfio_ap_drv.c:204:\tvfio_ap_matrix_dev_destroy();\ndrivers/s390/crypto/vfio_ap_drv.c:205:\tdebug_unregister(vfio_ap_dbf_info);\ndrivers/s390/crypto/vfio_ap_drv.c-206-}\ndrivers/s390/crypto/vfio_ap_drv.c-207-\ndrivers/s390/crypto/vfio_ap_drv.c:208:module_init(vfio_ap_init);\n\n" }
15/2	2026/08/06 21:15	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 39449 output: 26 thoughts: 156 Thoughts: Analyzing the Potential for VFIO-AP Exploitation via Syzkaller Okay, let's break this down. My initial observation is that the `vfio_ap` module seems to register a matrix device, and then an mdev driver. That's the setup. And Syzkaller, which I'm very familiar with, can create these mdevs, which immediately raises a critical question: Can we reach and exploit `vfio_ap` functionality even without the presence of physical AP hardware? My hypothesis rests on that initial question. I'm going to dig a little deeper, I'm going to consider the `vfio_ap_matrix_dev_create` function. I see that it appears to succeed even if the `test_facility(12)` check fails. That's a key observation, something that may be important. The driver then registers itself which looks very interesting. So, can Syzkaller create a `vfio_ap` mdev. This is the crucial next step. I know Syzkaller has descriptions for mdevs in files like `sys/linux/sysfs_mdev.txt`. I need to confirm whether Syzkaller has descriptions for `vfio_ap` specifically, because if it does, it's very likely we have a potential attack vector to investigate. That's where I need to start my search.
16/2	2026/08/06 21:15	tool	grepper	0m Error: no matches Args: { "Expression": "vfio_ap", "PathPrefix": "sys/" } Results: { "error": "no matches" }
17/2	2026/08/06 21:15	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 39938 output: 23 thoughts: 391 Thoughts: My Analysis of the Patch's Worthiness for Fuzzing Okay, so the prompt just threw a curveball. It's reminding me that I absolutely cannot use my usual `grepper` on anything that's `sys/` or has `syz_` in it because that's all Syzkaller pseudo-syscall stuff and won't be in the actual kernel. Fine. Makes sense. But wait a sec... I don't see this `syz-grepper` in my available tools. Guess I'll have to use my brain instead! Let's think. The patch modifies `vfio_ap_mdev_set_kvm` and `vfio_ap_mdev_unset_kvm`. Those are, if I remember correctly, related to VFIO device setup and teardown – when a VFIO device is opened or closed. The real question is, can Syzkaller actually* create and interact with a VFIO AP device in a standard QEMU environment? If Syzkaller can generate the code to create an mdev, it can open it as well. That depends on whether the `vfio_ap` driver is enabled in typical configurations. Now, the prompt brings up the "WorthFuzzing=false" scenario: unreachable code in virtualized environments. It explicitly mentions things like USB gadget, MAC80211 HWsim, or vendor-specific hardware like PCIe switches or GPUs that need a physical card, which isn't emulated by QEMU. That's the key. VFIO AP is for passing through physical AP cards, isn't it? Does it need physical hardware to be present to even create an mdev? I should check `vfio_ap_mdev_probe` and `vfio_ap_mdev_init_dev`. That will give me the answer.
18/2	2026/08/06 21:15	tool	grepper	0m Args: { "Expression": "vfio_ap_mdev_probe" } Results: { "Output": "drivers/s390/crypto/vfio_ap_drv.c=58=static struct ap_driver vfio_ap_drv = {\ndrivers/s390/crypto/vfio_ap_drv.c:59:\t.probe = vfio_ap_mdev_probe_queue,\ndrivers/s390/crypto/vfio_ap_drv.c-60-\t.remove = vfio_ap_mdev_remove_queue,\n--\ndrivers/s390/crypto/vfio_ap_ops.c=783=static int vfio_ap_mdev_init_dev(struct vfio_device vdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-796-\ndrivers/s390/crypto/vfio_ap_ops.c:797:static int vfio_ap_mdev_probe(struct mdev_device mdev)\ndrivers/s390/crypto/vfio_ap_ops.c-798-{\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2369=static struct mdev_driver vfio_ap_matrix_driver = {\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2377-\t},\ndrivers/s390/crypto/vfio_ap_ops.c:2378:\t.probe = vfio_ap_mdev_probe,\ndrivers/s390/crypto/vfio_ap_ops.c-2379-\t.remove = vfio_ap_mdev_remove,\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2405=void vfio_ap_mdev_unregister(void)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2410-\ndrivers/s390/crypto/vfio_ap_ops.c:2411:int vfio_ap_mdev_probe_queue(struct ap_device apdev)\ndrivers/s390/crypto/vfio_ap_ops.c-2412-{\n--\ndrivers/s390/crypto/vfio_ap_private.h=156=void vfio_ap_mdev_unregister(void);\ndrivers/s390/crypto/vfio_ap_private.h-157-\ndrivers/s390/crypto/vfio_ap_private.h:158:int vfio_ap_mdev_probe_queue(struct ap_device queue);\ndrivers/s390/crypto/vfio_ap_private.h-159-void vfio_ap_mdev_remove_queue(struct ap_device *queue);\n" }
19/2	2026/08/06 21:15	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 41450 output: 45 thoughts: 70 Thoughts: Here's my summary, as I understand the situation: Probing the Crypto Hardware with VFIO-AP Okay, so I'm digging into the VFIO-AP implementation for crypto hardware on s390 systems. The key is to understand how the system discovers and initializes the devices. My immediate focus is on the `vfio_ap_mdev_probe` function. That's the entry point, the first place the driver gets a shot at a new mdev, so it's critical to see what it's doing. I'm also going to track how `vfio_ap_mdev_init_dev` fits in as it is the follow-up step. I’m thinking they're probably both defined in `drivers/s390/crypto/vfio_ap_ops.c`. I need to figure out how these functions are connected and the logic flow. This seems to be the core of how the VFIO driver interacts with the underlying AP hardware and how it handles the mediated device, as well as how the hardware is detected. This is a crucial area to understanding the overall architecture and how the system virtualizes the crypto hardware to the user.
20/2	2026/08/06 21:15	tool	read-file	0m Args: { "File": "drivers/s390/crypto/vfio_ap_ops.c", "FirstLine": 783, "LineCount": 50 } Results: { "Contents": " 783:\tstatic int vfio_ap_mdev_init_dev(struct vfio_device vdev)\n 784:\t{\n 785:\t\tstruct ap_matrix_mdev matrix_mdev =\n 786:\t\t\tcontainer_of(vdev, struct ap_matrix_mdev, vdev);\n 787:\t\n 788:\t\tmatrix_mdev-\u003emdev = to_mdev_device(vdev-\u003edev);\n 789:\t\tvfio_ap_matrix_init(\u0026matrix_dev-\u003einfo, \u0026matrix_mdev-\u003ematrix);\n 790:\t\tmatrix_mdev-\u003epqap_hook = handle_pqap;\n 791:\t\tvfio_ap_matrix_init(\u0026matrix_dev-\u003einfo, \u0026matrix_mdev-\u003eshadow_apcb);\n 792:\t\thash_init(matrix_mdev-\u003eqtable.queues);\n 793:\t\n 794:\t\treturn 0;\n 795:\t}\n 796:\t\n 797:\tstatic int vfio_ap_mdev_probe(struct mdev_device mdev)\n 798:\t{\n 799:\t\tstruct ap_matrix_mdev matrix_mdev;\n 800:\t\tint ret;\n 801:\t\n 802:\t\tmatrix_mdev = vfio_alloc_device(ap_matrix_mdev, vdev, \u0026mdev-\u003edev,\n 803:\t\t\t\t\t\t\u0026vfio_ap_matrix_dev_ops);\n 804:\t\tif (IS_ERR(matrix_mdev))\n 805:\t\t\treturn PTR_ERR(matrix_mdev);\n 806:\t\n 807:\t\tret = vfio_register_emulated_iommu_dev(\u0026matrix_mdev-\u003evdev);\n 808:\t\tif (ret)\n 809:\t\t\tgoto err_put_vdev;\n 810:\t\tmatrix_mdev-\u003ereq_trigger = NULL;\n 811:\t\tmatrix_mdev-\u003ecfg_chg_trigger = NULL;\n 812:\t\tdev_set_drvdata(\u0026mdev-\u003edev, matrix_mdev);\n 813:\t\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\n 814:\t\tlist_add(\u0026matrix_mdev-\u003enode, \u0026matrix_dev-\u003emdev_list);\n 815:\t\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\n 816:\t\treturn 0;\n 817:\t\n 818:\terr_put_vdev:\n 819:\t\tvfio_put_device(\u0026matrix_mdev-\u003evdev);\n 820:\t\treturn ret;\n 821:\t}\n 822:\t\n 823:\tstatic void vfio_ap_mdev_link_queue(struct ap_matrix_mdev matrix_mdev,\n 824:\t\t\t\t\t struct vfio_ap_queue q)\n 825:\t{\n 826:\t\tif (!q \|\| vfio_ap_mdev_get_queue(matrix_mdev, q-\u003eapqn))\n 827:\t\t\treturn;\n 828:\t\n 829:\t\tq-\u003ematrix_mdev = matrix_mdev;\n 830:\t\thash_add(matrix_mdev-\u003eqtable.queues, \u0026q-\u003emdev_qnode, q-\u003eapqn);\n 831:\t}\n 832:\t\n" }
21/2	2026/08/06 21:15	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 42705 output: 46 thoughts: 78 Thoughts: Okay, let's break this down. Understanding mdev Creation and VFIO Interaction Right, so I'm focusing on how this mdev (mediated device) is being created. It's becoming clear that the process doesn't necessarily depend on having any pre-existing physical AP (Accelerated Processing) queues. That's interesting. The key here seems to be the allocation of this `ap_matrix_mdev` structure and its subsequent registration. That's the core of the mdev itself. The real magic, the part where the virtual device actually hooks into KVM, seems to happen later, specifically when `vfio_ap_mdev_set_kvm` is called. That makes sense; it's the point where we're actually associating the virtual device with the VFIO infrastructure, linking it to a KVM instance. To get a clearer picture of that linkage, I need to check how the device is opened and configured. Let's delve into the function `vfio_ap_mdev_open_device` to see precisely how this happens. That's where the rubber meets the road, so to speak. Understanding the flow from allocation, registration to opening the device should give me a good understanding of the entire process.
22/2	2026/08/06 21:15	tool	read-file	0m Args: { "File": "drivers/s390/crypto/vfio_ap_ops.c", "FirstLine": 2048, "LineCount": 50 } Results: { "Contents": "2048:\tstatic int vfio_ap_mdev_open_device(struct vfio_device vdev)\n2049:\t{\n2050:\t\tstruct ap_matrix_mdev matrix_mdev =\n2051:\t\t\tcontainer_of(vdev, struct ap_matrix_mdev, vdev);\n2052:\t\n2053:\t\tif (!vdev-\u003ekvm)\n2054:\t\t\treturn -EINVAL;\n2055:\t\n2056:\t\treturn vfio_ap_mdev_set_kvm(matrix_mdev, vdev-\u003ekvm);\n2057:\t}\n2058:\t\n2059:\tstatic void vfio_ap_mdev_close_device(struct vfio_device vdev)\n2060:\t{\n2061:\t\tstruct ap_matrix_mdev matrix_mdev =\n2062:\t\t\tcontainer_of(vdev, struct ap_matrix_mdev, vdev);\n2063:\t\n2064:\t\tvfio_ap_mdev_unset_kvm(matrix_mdev);\n2065:\t}\n2066:\t\n2067:\tstatic void vfio_ap_mdev_request(struct vfio_device vdev, unsigned int count)\n2068:\t{\n2069:\t\tstruct device dev = vdev-\u003edev;\n2070:\t\tstruct ap_matrix_mdev *matrix_mdev;\n2071:\t\n2072:\t\tmatrix_mdev = container_of(vdev, struct ap_matrix_mdev, vdev);\n2073:\t\n2074:\t\tget_update_locks_for_mdev(matrix_mdev);\n2075:\t\n2076:\t\tif (matrix_mdev-\u003ekvm) {\n2077:\t\t\tkvm_arch_crypto_clear_masks(matrix_mdev-\u003ekvm);\n2078:\t\t\tsignal_guest_ap_cfg_changed(matrix_mdev);\n2079:\t\t}\n2080:\t\n2081:\t\tif (matrix_mdev-\u003ereq_trigger) {\n2082:\t\t\tif (!(count % 10))\n2083:\t\t\t\tdev_notice_ratelimited(dev,\n2084:\t\t\t\t\t\t \"Relaying device request to user (#%u)\\n\",\n2085:\t\t\t\t\t\t count);\n2086:\t\n2087:\t\t\teventfd_signal(matrix_mdev-\u003ereq_trigger);\n2088:\t\t} else if (count == 0) {\n2089:\t\t\tdev_notice(dev,\n2090:\t\t\t\t \"No device request registered, blocked until released by user\\n\");\n2091:\t\t}\n2092:\t\n2093:\t\trelease_update_locks_for_mdev(matrix_mdev);\n2094:\t}\n2095:\t\n2096:\tstatic int vfio_ap_mdev_get_device_info(unsigned long arg)\n2097:\t{\n" }
23/2	2026/08/06 21:15	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 43895 output: 16 thoughts: 349 Thoughts: Reaching the VFIO AP Locking Logic Okay, so I'm looking at this patch and tracing the code flow. It seems `vfio_ap_mdev_open_device` calls `vfio_ap_mdev_set_kvm`. That's the entry point. The crucial part here is how we get there. It's triggered by creating and opening a VFIO device. Syzkaller, from what I recall, has descriptions for VFIO and can create mdevs, according to `sys/linux/vfio.txt` or similar. I'm pretty sure it supports VFIO and can create these mdevs, which means `vfio_ap_mdev_set_kvm` is definitely reachable. The patch itself targets `vfio_ap_mdev_set_kvm`, and its counterpart, `vfio_ap_mdev_unset_kvm`, along with `get_update_locks_for_kvm` and `release_update_locks_for_kvm`. Given the functions are explicitly mentioned, that confirms these are all reachable. Since the patch modifies these functions, it's pretty clear this is addressing locking issues or, at the very least, altering the locking behavior. Given the modifications to core locking logic within VFIO AP, this is absolutely worth fuzzing. The question that remains is whether there are any hardware restrictions that need to be met. Thankfully, there are not; since `vfio_ap_mdev_probe` succeeds without a physical AP, `vfio_ap_mdev_open_device` does not have any further restrictions. However, `vfio_ap_mdev_set_kvm` does check `kvm->arch.crypto.crycbd`. So I'm going to dig deeper and look into when and how that is set.
24/2	2026/08/06 21:15	tool	grepper	0m Args: { "Expression": "crycbd" } Results: { "Output": "arch/s390/include/asm/kvm_host.h=530=struct kvm_s390_crypto {\n--\narch/s390/include/asm/kvm_host.h-533-\tcrypto_hook pqap_hook;\narch/s390/include/asm/kvm_host.h:534:\t__u32 crycbd;\narch/s390/include/asm/kvm_host.h-535-\t__u8 aes_kw;\n--\narch/s390/include/asm/kvm_host_types.h=137=struct kvm_s390_sie_block {\n--\narch/s390/include/asm/kvm_host_types.h-305-#define CRYCB_FORMAT2 0x00000003\narch/s390/include/asm/kvm_host_types.h:306:\t__u32\tcrycbd;\t\t\t/ 0x00fc /\narch/s390/include/asm/kvm_host_types.h-307-\t__u64\tgcr[16];\t\t/ 0x0100 /\n--\narch/s390/kvm/kvm-s390.c=3121=static void kvm_s390_set_crycb_format(struct kvm kvm)\narch/s390/kvm/kvm-s390.c-3122-{\narch/s390/kvm/kvm-s390.c:3123:\tkvm-\u003earch.crypto.crycbd = virt_to_phys(kvm-\u003earch.crypto.crycb);\narch/s390/kvm/kvm-s390.c-3124-\narch/s390/kvm/kvm-s390.c-3125-\t/* Clear the CRYCB format bits - i.e., set format 0 by default /\narch/s390/kvm/kvm-s390.c:3126:\tkvm-\u003earch.crypto.crycbd \u0026= ~(CRYCB_FORMAT_MASK);\narch/s390/kvm/kvm-s390.c-3127-\n--\narch/s390/kvm/kvm-s390.c-3132-\tif (kvm_s390_apxa_installed())\narch/s390/kvm/kvm-s390.c:3133:\t\tkvm-\u003earch.crypto.crycbd \|= CRYCB_FORMAT2;\narch/s390/kvm/kvm-s390.c-3134-\telse\narch/s390/kvm/kvm-s390.c:3135:\t\tkvm-\u003earch.crypto.crycbd \|= CRYCB_FORMAT1;\narch/s390/kvm/kvm-s390.c-3136-}\n--\narch/s390/kvm/kvm-s390.c=3153=void kvm_arch_crypto_set_masks(struct kvm kvm, unsigned long apm,\n--\narch/s390/kvm/kvm-s390.c-3159-\narch/s390/kvm/kvm-s390.c:3160:\tswitch (kvm-\u003earch.crypto.crycbd \u0026 CRYCB_FORMAT_MASK) {\narch/s390/kvm/kvm-s390.c-3161-\tcase CRYCB_FORMAT2: / APCB1 use 256 bits /\n--\narch/s390/kvm/kvm-s390.c=3642=static void kvm_s390_vcpu_crypto_setup(struct kvm_vcpu vcpu)\n--\narch/s390/kvm/kvm-s390.c-3650-\narch/s390/kvm/kvm-s390.c:3651:\tvcpu-\u003earch.sie_block-\u003ecrycbd = vcpu-\u003ekvm-\u003earch.crypto.crycbd;\narch/s390/kvm/kvm-s390.c-3652-\tvcpu-\u003earch.sie_block-\u003eecb3 \u0026= ~(ECB3_AES \| ECB3_DEA);\n--\narch/s390/kvm/priv.c=592=static int handle_pqap(struct kvm_vcpu vcpu)\n--\narch/s390/kvm/priv.c-630-\t/ APXA not installed and APID greater 64 or APQI greater 16 /\narch/s390/kvm/priv.c:631:\tif (!(vcpu-\u003ekvm-\u003earch.crypto.crycbd \u0026 0x02) \u0026\u0026 (reg0 \u0026 0x0000c0f0UL))\narch/s390/kvm/priv.c-632-\t\treturn kvm_s390_inject_program_int(vcpu, PGM_SPECIFICATION);\n--\narch/s390/kvm/vsie.c=318=static int shadow_crycb(struct kvm_vcpu vcpu, struct vsie_page vsie_page)\n--\narch/s390/kvm/vsie.c-321-\tstruct kvm_s390_sie_block scb_o = vsie_page-\u003escb_o;\narch/s390/kvm/vsie.c:322:\tconst uint32_t crycbd_o = READ_ONCE(scb_o-\u003ecrycbd);\narch/s390/kvm/vsie.c:323:\tconst u32 crycb_addr = crycbd_o \u0026 0x7ffffff8U;\narch/s390/kvm/vsie.c-324-\tunsigned long b1, b2;\n--\narch/s390/kvm/vsie.c-329-\tint key_msk = test_kvm_facility(vcpu-\u003ekvm, 76);\narch/s390/kvm/vsie.c:330:\tint fmt_o = crycbd_o \u0026 CRYCB_FORMAT_MASK;\narch/s390/kvm/vsie.c:331:\tint fmt_h = vcpu-\u003earch.sie_block-\u003ecrycbd \u0026 CRYCB_FORMAT_MASK;\narch/s390/kvm/vsie.c-332-\tint ret = 0;\narch/s390/kvm/vsie.c-333-\narch/s390/kvm/vsie.c:334:\tscb_s-\u003ecrycbd = 0;\narch/s390/kvm/vsie.c-335-\n--\narch/s390/kvm/vsie.c-388-\t}\narch/s390/kvm/vsie.c:389:\tscb_s-\u003ecrycbd = (u32)virt_to_phys(\u0026vsie_page-\u003ecrycb) \| CRYCB_FORMAT2;\narch/s390/kvm/vsie.c-390-\treturn 0;\n--\ndrivers/s390/crypto/vfio_ap_ops.c=1828=static int vfio_ap_mdev_set_kvm(struct ap_matrix_mdev matrix_mdev,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1830-{\ndrivers/s390/crypto/vfio_ap_ops.c:1831:\tif (kvm-\u003earch.crypto.crycbd) {\ndrivers/s390/crypto/vfio_ap_ops.c-1832-\t\tget_update_locks_for_kvm(kvm);\n--\ndrivers/s390/crypto/vfio_ap_ops.c=1879=static void vfio_ap_mdev_unset_kvm(struct ap_matrix_mdev matrix_mdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1882-\ndrivers/s390/crypto/vfio_ap_ops.c:1883:\tif (kvm \u0026\u0026 kvm-\u003earch.crypto.crycbd) {\ndrivers/s390/crypto/vfio_ap_ops.c-1884-\t\tget_update_locks_for_kvm(kvm);\n--\ntools/testing/selftests/kvm/include/s390/sie.h=20=struct kvm_s390_sie_block {\n--\ntools/testing/selftests/kvm/include/s390/sie.h-213-#define CRYCB_FORMAT2\t\t0x00000003\ntools/testing/selftests/kvm/include/s390/sie.h:214:\t__u32\tcrycbd;\t\t\t/* 0x00fc /\ntools/testing/selftests/kvm/include/s390/sie.h-215-\t__u64\tgcr[16];\t\t/ 0x0100 */\n" }
25/2	2026/08/06 21:15	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 47023 output: 19 thoughts: 710 Thoughts: Analyzing the Patch's Impact on VFIO-AP and KVM Integration Okay, let's break this down. My initial thought is: `kvm_s390_set_crycb_format` sets the `crycbd` structure. That function is called during the KVM VM initialization via `kvm_s390_crypto_init`, and ultimately from `kvm_arch_init_vm`. This means `kvm->arch.crypto.crycbd` is populated when a KVM VM instance is created. That's key because `vfio_ap_mdev_set_kvm` should execute its core logic if a `kvm` pointer is passed in. Right, and `vfio_ap_mdev_set_kvm` is called from `vfio_ap_mdev_open_device` and it uses `vdev->kvm`, so `vdev->kvm` becomes assigned when a VFIO device is connected to a KVM instance. So, using Syzkaller, which can open the VFIO device and uses ioctls like `KVM_DEV_VFIO_GROUP_ADD`, we can reach this code path and test it within a virtualized setup. Good. Now, let's revisit the patch itself. It's adding `pqap_hook_rwsem` to `get_update_locks_for_kvm` and also `release_update_locks_for_kvm`. The patch modifies `vfio_ap_mdev_set_kvm` in a way that suggests a functional change to the locking and state management logic. The previous checks for `crycbd` are gone. This indicates a significant change in how the `pqap_hook` is handled. Specifically, it seems to be ensuring that the hook is only set when not already set for another device attached to the same KVM instance. The `list_for_each_entry` loop is removed, and replaced with a check of `kvm->arch.crypto.pqap_hook`. So that's now a single check. This is all definitely worth fuzzing. The lock changes, the state management tweaks – these are ripe for concurrency bugs or unexpected behavior. We'll need to focus on interactions between multiple VFIO AP devices, KVM, and the AP hardware. As for configuration, we need to ensure that `CONFIG_VFIO_AP` is enabled. Let's quickly double-check that in `arch/s390/Kconfig` to be sure. Alright, now we know what to test, and the configurations required. Time to set up the fuzzing environment.
26/2	2026/08/06 21:16	tool	grepper	0m Args: { "Expression": "config VFIO_AP" } Results: { "Output": "arch/s390/Kconfig=823=config VFIO_CCW\n--\narch/s390/Kconfig-833-\narch/s390/Kconfig:834:config VFIO_AP\narch/s390/Kconfig-835-\tdef_tristate n\n" }
27/2	2026/08/06 21:16	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 48422 output: 37 thoughts: 22 Thoughts: Here's my analysis of the provided text, rendered as a first-person expert summary: Diving into the s390 Architecture Configuration Okay, so we're looking at the `arch/s390/Kconfig` file, specifically around line 834. I'm going to assume this section likely relates to some feature or configuration option within the s390 architecture. Given the context of a Kconfig file, it's probably defining a conditional build option, a hardware feature setting, or maybe even a driver configuration related to the IBM mainframe architecture. I'll need to carefully examine the surrounding code to understand the dependencies, default values, and help text associated with this specific configuration item. It could be something straightforward, or it might require a deeper understanding of the hardware capabilities, firmware interactions, or specific kernel subsystems within the s390 environment. Let's see what we can find.
28/2	2026/08/06 21:16	tool	read-file	0m Args: { "File": "arch/s390/Kconfig", "FirstLine": 830, "LineCount": 20 } Results: { "Contents": " 830:\t\n 831:\t\t To compile this driver as a module, choose M here: the\n 832:\t\t module will be called vfio_ccw.\n 833:\t\n 834:\tconfig VFIO_AP\n 835:\t\tdef_tristate n\n 836:\t\tprompt \"VFIO support for AP devices\"\n 837:\t\tdepends on KVM\n 838:\t\tdepends on VFIO\n 839:\t\tdepends on AP\n 840:\t\tselect VFIO_MDEV\n 841:\t\thelp\n 842:\t\t This driver grants access to Adjunct Processor (AP) devices\n 843:\t\t via the VFIO mediated device interface.\n 844:\t\n 845:\t\t To compile this driver as a module, choose M here: the module\n 846:\t\t will be called vfio_ap.\n 847:\t\n 848:\tendmenu\n 849:\t\n" }
29/2	2026/08/06 21:16	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 48940 output: 16 thoughts: 49 Thoughts: Okay, here's my interpretation of those thoughts, presented as my own mental process: VFIO-AP Configuration Conundrum Right, so to get this working, it seems that `CONFIG_VFIO_AP` is absolutely essential. Okay, obvious start. But, I need to figure out its dependencies to properly configure everything. It looks like it directly depends on `KVM`, `VFIO`, and `AP`. That's a reasonable set, I can work with that, makes sense to me. The interesting part is `AP`. Is `AP` referring to `CONFIG_ZCRYPT`? I'll need to double-check that definition in the kernel config... Let me go and dig that up.
30/2	2026/08/06 21:16	tool	grepper	0m Args: { "Expression": "config AP" } Results: { "Output": "Documentation/admin-guide/bootconfig.rst=287=to initrd image, user can notice it before boot.\n--\nDocumentation/admin-guide/bootconfig.rst-289-\nDocumentation/admin-guide/bootconfig.rst:290:Bootconfig APIs\nDocumentation/admin-guide/bootconfig.rst-291-===============\n--\narch/m68k/Kconfig.machine=29=config MAC\n--\narch/m68k/Kconfig.machine-40-\narch/m68k/Kconfig.machine:41:config APOLLO\narch/m68k/Kconfig.machine-42-\tbool \"Apollo support\"\n--\narch/powerpc/platforms/44x/Kconfig=291=config 476FPE\n--\narch/powerpc/platforms/44x/Kconfig-294-\narch/powerpc/platforms/44x/Kconfig:295:config APM821xx\narch/powerpc/platforms/44x/Kconfig-296-\tbool\n--\narch/s390/Kconfig=785=config EADM_SCH\n--\narch/s390/Kconfig-795-\narch/s390/Kconfig:796:config AP\narch/s390/Kconfig-797-\tdef_tristate y\n--\narch/s390/Kconfig-808-\narch/s390/Kconfig:809:config AP_DEBUG\narch/s390/Kconfig-810-\tdef_bool n\n--\narch/s390/Kconfig=885=config CMM_IUCV\n--\narch/s390/Kconfig-892-\narch/s390/Kconfig:893:config APPLDATA_BASE\narch/s390/Kconfig-894-\tdef_bool n\n--\narch/s390/Kconfig-908-\narch/s390/Kconfig:909:config APPLDATA_MEM\narch/s390/Kconfig-910-\tdef_tristate m\n--\narch/s390/Kconfig-925-\narch/s390/Kconfig:926:config APPLDATA_OS\narch/s390/Kconfig-927-\tdef_tristate m\n--\narch/s390/Kconfig-940-\narch/s390/Kconfig:941:config APPLDATA_NET_SUM\narch/s390/Kconfig-942-\tdef_tristate m\n--\narch/x86/Kconfig=2741=config X86_APM_BOOT\n--\narch/x86/Kconfig-2744-\narch/x86/Kconfig:2745:menuconfig APM\narch/x86/Kconfig-2746-\ttristate \"APM (Advanced Power Management) BIOS support\"\n--\narch/x86/Kconfig=2799=if APM\narch/x86/Kconfig-2800-\narch/x86/Kconfig:2801:config APM_IGNORE_USER_SUSPEND\narch/x86/Kconfig-2802-\tbool \"Ignore USER SUSPEND\"\n--\narch/x86/Kconfig-2807-\narch/x86/Kconfig:2808:config APM_DO_ENABLE\narch/x86/Kconfig-2809-\tbool \"Enable PM at boot time\"\n--\narch/x86/Kconfig-2824-\narch/x86/Kconfig:2825:config APM_CPU_IDLE\narch/x86/Kconfig-2826-\tdepends on CPU_IDLE\n--\narch/x86/Kconfig-2836-\narch/x86/Kconfig:2837:config APM_DISPLAY_BLANK\narch/x86/Kconfig-2838-\tbool \"Enable console blanking using APM\"\n--\narch/x86/Kconfig-2849-\narch/x86/Kconfig:2850:config APM_ALLOW_INTS\narch/x86/Kconfig-2851-\tbool \"Allow interrupts during APM BIOS calls\"\n--\ndrivers/char/Kconfig=213=config XILINX_HWICAP\n--\ndrivers/char/Kconfig-222-\ndrivers/char/Kconfig:223:config APPLICOM\ndrivers/char/Kconfig-224-\ttristate \"Applicom intelligent fieldbus card support\"\n--\ndrivers/clk/qcom/Kconfig=290=config QCOM_CLK_RPMH\n--\ndrivers/clk/qcom/Kconfig-298-\ndrivers/clk/qcom/Kconfig:299:config APQ_GCC_8084\ndrivers/clk/qcom/Kconfig-300-\ttristate \"APQ8084 Global Clock Controller\"\n--\ndrivers/clk/qcom/Kconfig-307-\ndrivers/clk/qcom/Kconfig:308:config APQ_MMCC_8084\ndrivers/clk/qcom/Kconfig-309-\ttristate \"APQ8084 Multimedia Clock Controller\"\n--\ndrivers/dma/Kconfig=78=config AMCC_PPC440SPE_ADMA\n--\ndrivers/dma/Kconfig-87-\ndrivers/dma/Kconfig:88:config APPLE_ADMAC\ndrivers/dma/Kconfig-89-\ttristate \"Apple ADMAC support\"\n--\ndrivers/firmware/efi/Kconfig=154=config EFI_DEV_PATH_PARSER\n--\ndrivers/firmware/efi/Kconfig-156-\ndrivers/firmware/efi/Kconfig:157:config APPLE_PROPERTIES\ndrivers/firmware/efi/Kconfig-158-\tbool \"Apple Device Properties\"\n--\ndrivers/iio/light/Kconfig=66=config AL3320A\n--\ndrivers/iio/light/Kconfig-75-\ndrivers/iio/light/Kconfig:76:config APDS9160\ndrivers/iio/light/Kconfig-77-\ttristate \"APDS9160 combined als and proximity sensor\"\n--\ndrivers/iio/light/Kconfig-86-\ndrivers/iio/light/Kconfig:87:config APDS9300\ndrivers/iio/light/Kconfig-88-\ttristate \"APDS9300 ambient light sensor\"\n--\ndrivers/iio/light/Kconfig-96-\ndrivers/iio/light/Kconfig:97:config APDS9306\ndrivers/iio/light/Kconfig-98-\ttristate \"Avago APDS9306 Ambient Light Sensor\"\n--\ndrivers/iio/light/Kconfig-108-\ndrivers/iio/light/Kconfig:109:config APDS9960\ndrivers/iio/light/Kconfig-110-\ttristate \"Avago APDS9960 gesture/RGB/ALS/proximity sensor\"\n--\ndrivers/iommu/Kconfig=296=config SPAPR_TCE_IOMMU\n--\ndrivers/iommu/Kconfig-303-\ndrivers/iommu/Kconfig:304:config APPLE_DART\ndrivers/iommu/Kconfig-305-\ttristate \"Apple DART IOMMU Support\"\n--\ndrivers/irqchip/Kconfig=788=config IRQ_IDT3243X\n--\ndrivers/irqchip/Kconfig-792-\ndrivers/irqchip/Kconfig:793:config APPLE_AIC\ndrivers/irqchip/Kconfig-794-\tbool \"Apple Interrupt Controller (AIC)\"\n--\ndrivers/misc/Kconfig=327=config SGI_GRU_DEBUG\n--\ndrivers/misc/Kconfig-333-\ndrivers/misc/Kconfig:334:config APDS9802ALS\ndrivers/misc/Kconfig-335-\ttristate \"Medfield Avago APDS9802 ALS Sensor module\"\n--\ndrivers/net/ethernet/8390/Kconfig=106=config NE2K_PCI\n--\ndrivers/net/ethernet/8390/Kconfig-123-\ndrivers/net/ethernet/8390/Kconfig:124:config APNE\ndrivers/net/ethernet/8390/Kconfig-125-\ttristate \"PCMCIA NE2000 support\"\n--\ndrivers/net/wireless/realtek/rtw89/pci.c=3320=static int rtw89_pci_cfg_dac(struct rtw89_dev rtwdev, bool force)\n--\ndrivers/net/wireless/realtek/rtw89/pci.c-3332-\ndrivers/net/wireless/realtek/rtw89/pci.c:3333:\t/ Configure DAC only via PCI config API, not DBI interfaces /\ndrivers/net/wireless/realtek/rtw89/pci.c-3334-\tret = pci_read_config_byte(pdev, RTW89_PCIE_L1_CTRL, \u0026val);\n--\ndrivers/perf/Kconfig=253=config MARVELL_CN10K_TAD_PMU\n--\ndrivers/perf/Kconfig-259-\ndrivers/perf/Kconfig:260:config APPLE_M1_CPU_PMU\ndrivers/perf/Kconfig-261-\tbool \"Apple M1 CPU PMU support\"\n--\ndrivers/platform/x86/Kconfig=194=config ADV_SWBUTTON\n--\ndrivers/platform/x86/Kconfig-204-\ndrivers/platform/x86/Kconfig:205:config APPLE_GMUX\ndrivers/platform/x86/Kconfig-206-\ttristate \"Apple Gmux Driver\"\n--\ndrivers/pmdomain/apple/Kconfig=3=if ARCH_APPLE \|\| COMPILE_TEST\ndrivers/pmdomain/apple/Kconfig-4-\ndrivers/pmdomain/apple/Kconfig:5:config APPLE_PMGR_PWRSTATE\ndrivers/pmdomain/apple/Kconfig-6-\tbool \"Apple SoC PMGR power state control\"\n--\ndrivers/power/supply/Kconfig=18=config POWER_SUPPLY_HWMON\n--\ndrivers/power/supply/Kconfig-30-\ndrivers/power/supply/Kconfig:31:config APM_POWER\ndrivers/power/supply/Kconfig-32-\ttristate \"APM emulation for class batteries\"\n--\ndrivers/soc/apple/Kconfig=5=menu \"Apple SoC drivers\"\ndrivers/soc/apple/Kconfig-6-\ndrivers/soc/apple/Kconfig:7:config APPLE_MAILBOX\ndrivers/soc/apple/Kconfig-8-\ttristate \"Apple SoC mailboxes\"\n--\ndrivers/soc/apple/Kconfig-18-\ndrivers/soc/apple/Kconfig:19:config APPLE_RTKIT\ndrivers/soc/apple/Kconfig-20-\ttristate \"Apple RTKit co-processor IPC protocol\"\n--\ndrivers/soc/apple/Kconfig-30-\ndrivers/soc/apple/Kconfig:31:config APPLE_SART\ndrivers/soc/apple/Kconfig-32-\ttristate \"Apple SART DMA address filter\"\n--\ndrivers/soc/apple/Kconfig-40-\ndrivers/soc/apple/Kconfig:41:config APPLE_TUNABLE\ndrivers/soc/apple/Kconfig-42-\ttristate\n--\ndrivers/usb/misc/Kconfig=147=config USB_QCOM_EUD\n--\ndrivers/usb/misc/Kconfig-158-\ndrivers/usb/misc/Kconfig:159:config APPLE_MFI_FASTCHARGE\ndrivers/usb/misc/Kconfig-160-\ttristate \"Fast charge control for iOS devices\"\n--\ndrivers/video/Kconfig=6=menu \"Graphics support\"\ndrivers/video/Kconfig-7-\ndrivers/video/Kconfig:8:config APERTURE_HELPERS\ndrivers/video/Kconfig-9-\tbool\n--\ndrivers/watchdog/Kconfig=1111=config MSC313E_WATCHDOG\n--\ndrivers/watchdog/Kconfig-1122-\ndrivers/watchdog/Kconfig:1123:config APPLE_WATCHDOG\ndrivers/watchdog/Kconfig-1124-\ttristate \"Apple SoC watchdog\"\n--\nfs/xfs/xfs_super.c=1652=xfs_fs_fill_super(\n--\nfs/xfs/xfs_super.c-1664-\t is guaranteed to have been completed by either the old mount API or\nfs/xfs/xfs_super.c:1665:\t * the newer fsopen/fsconfig API.\nfs/xfs/xfs_super.c-1666-\t */\n--\nkernel/power/Kconfig=310=config PM_TRACE_RTC\n--\nkernel/power/Kconfig-327-\nkernel/power/Kconfig:328:config APM_EMULATION\nkernel/power/Kconfig-329-\ttristate \"Advanced Power Management Emulation\"\n" }
31/2	2026/08/06 21:16	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 52508 output: 37 thoughts: 62 Thoughts: Examining the s390 Architecture Configuration Okay, so I'm looking at this `CONFIG_AP` option, and my first instinct is to trace where it's defined. Right, the path is `arch/s390/Kconfig:796`. That tells me the context is the s390 architecture's configuration file. Now I'm mentally parsing the dependencies. If we're enabling `CONFIG_AP`, logically, we're likely going to need a few other elements to come along for the ride. I'm thinking immediately about `VFIO_AP`, `KVM`, and `VFIO`, and of course the base `AP` component itself. Alright, let's just go ahead and dive into the `arch/s390/Kconfig` file and confirm my thinking. I'll search for the `AP` configuration option and see what the dependencies or implied connections are there. This should give me a clearer picture of what enabling this involves at the kernel level.
32/2	2026/08/06 21:16	tool	read-file	0m Args: { "File": "arch/s390/Kconfig", "FirstLine": 790, "LineCount": 20 } Results: { "Contents": " 790:\t\t This driver allows usage of EADM subchannels. EADM subchannels act\n 791:\t\t as a communication vehicle for SCM increments.\n 792:\t\n 793:\t\t To compile this driver as a module, choose M here: the\n 794:\t\t module will be called eadm_sch.\n 795:\t\n 796:\tconfig AP\n 797:\t\tdef_tristate y\n 798:\t\tprompt \"Support for Adjunct Processors (ap)\"\n 799:\t\thelp\n 800:\t\t This driver allows usage to Adjunct Processor (AP) devices via\n 801:\t\t the ap bus, cards and queues. Supported Adjunct Processors are\n 802:\t\t the CryptoExpress Cards (CEX).\n 803:\t\n 804:\t\t To compile this driver as a module, choose M here: the\n 805:\t\t module will be called ap.\n 806:\t\n 807:\t\t If unsure, say Y (default).\n 808:\t\n 809:\tconfig AP_DEBUG\n" }
33/2	2026/08/06 21:16	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 53121 output: 39 thoughts: 367 Thoughts: My Initial Thoughts on VFIO-AP Kernel Module Symbol Analysis Alright, let's break this down. `CONFIG_AP` is the foundation, Adjunct Processor support. Okay, got it. Now, what's required? The list is: `VFIO_AP`, `KVM`, `VFIO`, and `AP`. Hold on, `AP` is tristate, defaulted to 'y'. Great, that's taken care of. `VFIO_AP` is defaulted to 'n' though. So, the key is enabling `VFIO_AP`. It depends on `KVM`, `VFIO`, and `AP`, so I need to be mindful of those dependencies. `KVM` and `VFIO` are pretty standard fare though, so I'm going to focus on enabling `VFIO_AP`. Now, for symbol analysis, I need to focus on these: `vfio_ap_mdev_set_kvm`, `vfio_ap_mdev_unset_kvm`, `vfio_ap_mdev_open_device`, `vfio_ap_mdev_close_device`, `vfio_ap_mdev_probe`, and `vfio_ap_mdev_init_dev`. Let's see if `vfio_ap_mdev_set_kvm` is static. Yes, it is. But, wait... the prompt prefers non-static, non-inlined API entrypoints over internal static helper functions. Those static functions are often inlined by the compiler, and don't have distinct symbol addresses. Okay, I'll keep that in mind. `vfio_ap_mdev_open_device` is also static, but it's used as a callback in `vfio_ap_matrix_dev_ops`. So, I'll need to check `vfio_ap_ops.c` now to find the non-static functions for entry points.
34/2	2026/08/06 21:16	tool	grepper	0m Args: { "Expression": "^[a-zA-Z_][a-zA-Z0-9_]* vfio_ap_mdev" } Results: { "Output": "drivers/s390/crypto/vfio_ap_ops.c=2369=static struct mdev_driver vfio_ap_matrix_driver = {\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2381-\ndrivers/s390/crypto/vfio_ap_ops.c:2382:int vfio_ap_mdev_register(void)\ndrivers/s390/crypto/vfio_ap_ops.c-2383-{\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2404-\ndrivers/s390/crypto/vfio_ap_ops.c:2405:void vfio_ap_mdev_unregister(void)\ndrivers/s390/crypto/vfio_ap_ops.c-2406-{\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2410-\ndrivers/s390/crypto/vfio_ap_ops.c:2411:int vfio_ap_mdev_probe_queue(struct ap_device apdev)\ndrivers/s390/crypto/vfio_ap_ops.c-2412-{\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2464-\ndrivers/s390/crypto/vfio_ap_ops.c:2465:void vfio_ap_mdev_remove_queue(struct ap_device apdev)\ndrivers/s390/crypto/vfio_ap_ops.c-2466-{\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2527- /\ndrivers/s390/crypto/vfio_ap_ops.c:2528:int vfio_ap_mdev_resource_in_use(unsigned long apm, unsigned long aqm)\ndrivers/s390/crypto/vfio_ap_ops.c-2529-{\n--\ndrivers/s390/crypto/vfio_ap_private.h=143=struct vfio_ap_queue {\n--\ndrivers/s390/crypto/vfio_ap_private.h-154-\ndrivers/s390/crypto/vfio_ap_private.h:155:int vfio_ap_mdev_register(void);\ndrivers/s390/crypto/vfio_ap_private.h:156:void vfio_ap_mdev_unregister(void);\ndrivers/s390/crypto/vfio_ap_private.h-157-\ndrivers/s390/crypto/vfio_ap_private.h:158:int vfio_ap_mdev_probe_queue(struct ap_device queue);\ndrivers/s390/crypto/vfio_ap_private.h:159:void vfio_ap_mdev_remove_queue(struct ap_device queue);\ndrivers/s390/crypto/vfio_ap_private.h-160-\ndrivers/s390/crypto/vfio_ap_private.h:161:int vfio_ap_mdev_resource_in_use(unsigned long apm, unsigned long *aqm);\ndrivers/s390/crypto/vfio_ap_private.h-162-\n" }
35/2	2026/08/06 21:16	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 54802 output: 26 thoughts: 525 Thoughts: Identifying Key API Entry Points for Analysis Okay, let's break this down. My initial thought process focused on identifying the key entry points into this code, particularly the modified portions. The prompt emphasizes non-static, non-inlined API functions, which are distinct, callable units. I started by listing the obvious non-static functions: `vfio_ap_mdev_register`, `vfio_ap_mdev_unregister`, `vfio_ap_mdev_probe_queue`, `vfio_ap_mdev_remove_queue`, and `vfio_ap_mdev_resource_in_use`. These are clearly entry points. Then, I started to question the static ones. `vfio_ap_mdev_open_device` is a callback within `vfio_device_ops`, so even though it's static, its address is taken, ensuring it won't be fully inlined. It's essentially an entry point. The same is true for `vfio_ap_mdev_close_device`. I considered `vfio_ap_mdev_ioctl` and `vfio_ap_mdev_probe`, but quickly dismissed them, as they were static and likely internal helpers. I then revisited the idea of listing `vfio_ap_mdev_set_kvm` and `vfio_ap_mdev_unset_kvm` directly, as they are crucial for setting up the KVM context. Although they were static, `vfio_ap_mdev_set_kvm` is called from `vfio_ap_mdev_open_device` and is likely not fully inlined because of its size. However, given the prompt's preference, `vfio_ap_mdev_open_device` and `vfio_ap_mdev_close_device` are the key entry points for the modified code. These are callbacks, so they are not inlined, and they are important to understand how the KVM context is set and unset. I'll double-check to confirm that `vfio_ap_mdev_set_kvm` and `vfio_ap_mdev_unset_kvm` aren't called from anywhere else, just to be thorough.
36/2	2026/08/06 21:16	tool	grepper	0m Args: { "Expression": "vfio_ap_mdev_set_kvm" } Results: { "Output": "drivers/s390/crypto/vfio_ap_ops.c=1813=static const struct attribute_group vfio_ap_mdev_attr_groups[] = {\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1818-/\ndrivers/s390/crypto/vfio_ap_ops.c:1819: vfio_ap_mdev_set_kvm - sets all data for @matrix_mdev that are needed\ndrivers/s390/crypto/vfio_ap_ops.c-1820- * to manage AP resources for the guest whose state is represented by @kvm\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1827- /\ndrivers/s390/crypto/vfio_ap_ops.c:1828:static int vfio_ap_mdev_set_kvm(struct ap_matrix_mdev matrix_mdev,\ndrivers/s390/crypto/vfio_ap_ops.c-1829-\t\t\t\tstruct kvm kvm)\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2048=static int vfio_ap_mdev_open_device(struct vfio_device vdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2055-\ndrivers/s390/crypto/vfio_ap_ops.c:2056:\treturn vfio_ap_mdev_set_kvm(matrix_mdev, vdev-\u003ekvm);\ndrivers/s390/crypto/vfio_ap_ops.c-2057-}\n" }
37/2	2026/08/06 21:16	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 56279 output: 26 thoughts: 35 Thoughts: Okay, here's my interpretation of those thoughts, framed as an expert's internal monologue: Investigating the Caller Context Hmm, so this particular function, whatever it is, is only called from `vfio_ap_mdev_open_device`. Interesting. And, of course, from `vfio_ap_mdev_unset_kvm`. That's a limited set of callers. Knowing this is key, as it dramatically constrains the scenarios I need to consider when debugging or refactoring. This information will inform my understanding of the execution flow and potential side effects within the VFIO architecture. This also helps with understanding and debugging how the VFIO AP (Address-Space Pass-Through) functionality handles device access and KVM interactions.
38/2	2026/08/06 21:16	tool	grepper	0m Args: { "Expression": "vfio_ap_mdev_unset_kvm" } Results: { "Output": "drivers/s390/crypto/vfio_ap_ops.c=1860=static void vfio_ap_mdev_dma_unmap(struct vfio_device vdev, u64 iova,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1873-/\ndrivers/s390/crypto/vfio_ap_ops.c:1874: vfio_ap_mdev_unset_kvm - performs clean-up of resources no longer needed\ndrivers/s390/crypto/vfio_ap_ops.c-1875- * by @matrix_mdev.\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1878- /\ndrivers/s390/crypto/vfio_ap_ops.c:1879:static void vfio_ap_mdev_unset_kvm(struct ap_matrix_mdev matrix_mdev)\ndrivers/s390/crypto/vfio_ap_ops.c-1880-{\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2059=static void vfio_ap_mdev_close_device(struct vfio_device *vdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2063-\ndrivers/s390/crypto/vfio_ap_ops.c:2064:\tvfio_ap_mdev_unset_kvm(matrix_mdev);\ndrivers/s390/crypto/vfio_ap_ops.c-2065-}\n" }
39/2	2026/08/06 21:16	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 56918 output: 34 thoughts: 190 Thoughts: My Analysis of VFIO-AP Related Functions Alright, let me break this down. My initial focus is on the `vfio_ap_mdev_close_device` function, since that's where the initial prompt directed me. I'm going to list `vfio_ap_mdev_open_device` and `vfio_ap_mdev_close_device` as my primary FocusSymbols. I'll also include `vfio_ap_mdev_set_kvm` and `vfio_ap_mdev_unset_kvm` just to be thorough, especially if they aren't inlined anywhere. Now, let's circle back to the configurations. I need to explicitly enable `VFIO_AP`. It looks like `KVM` and `VFIO` are baseline and assumed in most virtualization and syzkaller contexts. But hold on... `VFIO_AP` is defined as `def_tristate n`? That confirms it, I definitely need to enable it. Just to be completely sure, let me check the `drivers/s390/crypto/Makefile` file to make sure I haven't missed anything else.
40/2	2026/08/06 21:16	tool	grepper	0m Args: { "Expression": "vfio_ap", "PathPrefix": "drivers/s390/crypto/Makefile" } Results: { "Output": "drivers/s390/crypto/Makefile=34=obj-$(CONFIG_PKEY_UV) += pkey-uv.o\n--\ndrivers/s390/crypto/Makefile-36-# adjunct processor matrix\ndrivers/s390/crypto/Makefile:37:vfio_ap-objs := vfio_ap_drv.o vfio_ap_ops.o\ndrivers/s390/crypto/Makefile:38:obj-$(CONFIG_VFIO_AP) += vfio_ap.o\n" }
41/2	2026/08/06 21:16	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 57532 output: 169 thoughts: 434 Thoughts: VFIO AP Driver Reachability in a Virtualized Environment Okay, so `CONFIG_VFIO_AP` is the key configuration option here, that much is clear. The question is, is this code path accessible in a standard QEMU environment? The answer, thankfully, is yes. We can leverage syzkaller to create an mdev device through sysfs, and then open the VFIO device. The beauty of the `vfio_ap` driver is that it doesn't actually require any physical AP hardware to get that mdev device created. We confirmed this by examining the functions `vfio_ap_mdev_probe` and `vfio_ap_matrix_dev_create`. Critically, even if `test_facility(12)` returns false (meaning no AP instructions are available on the physical host), `vfio_ap_matrix_dev_create` still succeeds. All `vfio_ap_mdev_probe` seems to do is allocate memory and register the device. Then, when the VFIO device gets opened, `vfio_ap_mdev_open_device` is invoked. This in turn calls `vfio_ap_mdev_set_kvm`, which checks `kvm->arch.crypto.crycbd`. The crucial part here is that `crycbd` gets set when a KVM VM is created, irrespective of the presence of physical AP hardware. It just populates either `CRYCB_FORMAT1` or `CRYCB_FORMAT2`. Therefore, this entire code path is completely reachable within a virtualized setting, without needing to worry about the underlying hardware. So, let's summarize the key takeaways: * WorthFuzzing: True - Definitely worth fuzzing, this is reachable. * FocusSymbols: I'm going to want to focus on: * `vfio_ap_mdev_open_device` * `vfio_ap_mdev_close_device` * `vfio_ap_mdev_set_kvm` * `vfio_ap_mdev_unset_kvm` * EnableConfigs: Clearly, just `VFIO_AP` is needed. The reasoning is solid: The patch affects locking and state management in the VFIO AP driver when attaching and detaching mediated devices from KVM guests. Since the driver can be loaded, mdevs can be created and opened in a virtual environment via sysfs and VFIO ioctls, making this a prime candidate for fuzzing.
42/2	2026/08/06 21:17	tool	set-results	0m Error: the following configs do not exist in the kernel tree: VFIO_AP Args: { "EnableConfigs": [ "VFIO_AP" ], "FocusSymbols": [ "vfio_ap_mdev_open_device", "vfio_ap_mdev_close_device", "vfio_ap_mdev_set_kvm", "vfio_ap_mdev_unset_kvm" ], "Reasoning": "The patch modifies locking semantics and state management in the VFIO AP driver when a mediated device is attached to or detached from a KVM guest. The vfio_ap driver can be loaded and mdevs can be created and opened in a virtualized environment without requiring physical AP hardware, making this code reachable and fuzzable via sysfs and VFIO ioctls.", "WorthFuzzing": true } Results: { "error": "the following configs do not exist in the kernel tree: VFIO_AP" }
43/2	2026/08/06 21:17	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 58717 output: 19 thoughts: 30 Thoughts: Here's my thought process, as if I were considering this issue: Investigating a Missing Configuration Option Okay, hold on a second. I was under the impression that `VFIO_AP` was a valid configuration option for s390, but something's not adding up. I'm getting a feeling that I'm chasing a phantom here. Let's not assume, though, and jump to conclusions. The best approach is to double-check the source of truth for these s390 configuration options. I need to go back to the `arch/s390/Kconfig` file and confirm, definitively, whether or not `VFIO_AP` is actually defined there. This is a critical first step. I can't build my analysis on a false premise. I'll need to meticulously scan through that Kconfig to be absolutely sure. Then I can proceed with further debugging, based on the actual Kconfig reality.
44/2	2026/08/06 21:17	tool	grepper	0m Args: { "Expression": "config VFIO_AP" } Results: { "Output": "arch/s390/Kconfig=823=config VFIO_CCW\n--\narch/s390/Kconfig-833-\narch/s390/Kconfig:834:config VFIO_AP\narch/s390/Kconfig-835-\tdef_tristate n\n" }
45/2	2026/08/06 21:17	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 59061 output: 169 thoughts: 241 Thoughts: VFIO_AP Conundrum Okay, so I'm seeing that the `VFIO_AP` option is, in fact, defined within `arch/s390/Kconfig`. That's a bit perplexing because the `set-results` tool just told me it doesn't exist. Hmm, I bet the tool is checking against, say, an x86_64-based configuration. That would make sense, as these tools can sometimes be overly generalized. The error message is clear: "the following configs do not exist in the kernel tree: VFIO_AP". Right, I need to verify that there isn't a typo or some other obvious mistake on my part. Yep, I confirm the path is correct: `arch/s390/Kconfig` definitely has `config VFIO_AP`. This makes me think the tool might be looking at a default defconfig, or perhaps comparing against a particular architecture other than the one I'm working with. I'm tempted to just resubmit it, but wait, I know the tool rejected it. Should I omit it altogether, or just provide it and ignore the error? Ah, I remember the prompt. It says to use the tool, then ignore the results. "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." So I can simply call it again and disregard the failure? But, wait a second... if it failed, did the tool actually save the results, the first time I called it? I need to check. Okay, I'll call it again just to be sure.
46/2	2026/08/06 21:17	tool	set-results	0m Error: the following configs do not exist in the kernel tree: VFIO_AP Args: { "EnableConfigs": [ "VFIO_AP" ], "FocusSymbols": [ "vfio_ap_mdev_open_device", "vfio_ap_mdev_close_device", "vfio_ap_mdev_set_kvm", "vfio_ap_mdev_unset_kvm" ], "Reasoning": "The patch modifies locking semantics and state management in the VFIO AP driver when a mediated device is attached to or detached from a KVM guest. The vfio_ap driver can be loaded and mdevs can be created and opened in a virtualized environment without requiring physical AP hardware, making this code reachable and fuzzable via sysfs and VFIO ioctls.", "WorthFuzzing": true } Results: { "error": "the following configs do not exist in the kernel tree: VFIO_AP" }
47/2	2026/08/06 21:17	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 59858 output: 335 thoughts: 50 Thoughts: My Immediate Response to the Situation Okay, the instructions are clear: disregard any errors from the previous tool. No need to get bogged down in details that the prompt explicitly tells me to bypass. I understand my task and I'm moving forward. I'm operating on the assumption that `VFIO_AP` is indeed defined within `arch/s390/Kconfig`. This seems like a reasonable assumption based on my prior knowledge and experience. Now, with this confirmed, I'll proceed directly to deliver the requested final response, as planned. There's no need for further investigation or verification at this point.
48/2	2026/08/06 21:17	llm	patch-evaluator	0m Model: gemini-3.1-pro-preview Args: null Results: null Tokens: input: 55516 output: 193 thoughts: 356 Thoughts: Troubleshooting Configuration Discrepancy Okay, so `set-results` just crapped out with a "configs do not exist" error, specifically mentioning `VFIO_AP`. This is puzzling. Why isn't it seeing the configuration? My first thought is, am I mistakenly thinking this is an x86-specific thing? Does the tool make assumptions about the architecture and check configs only against x86_64? I need to verify. The tool should be checking against the kernel tree, and `VFIO_AP` is in `arch/s390/Kconfig`. If the tool is using a script internally, maybe it is only designed to check against x86 configurations. I need to make sure I'm not missing something in the `arch/s390/Kconfig`. Ah yes, `VFIO_AP` is definitely defined in `arch/s390/Kconfig`. If the tool isn't recognizing it, perhaps I should just omit it entirely, providing only `KVM` and `VFIO`. Let me just be absolutely sure... Wait, the tool's error message explicitly says `VFIO_AP` doesn't exist. Now that I think about it, should I be using `CONFIG_VFIO_AP` instead? Actually, I could just omit the config altogether if it's not recognized. Maybe I should just try `AP`? Okay, let me check the relevant `Makefile`. Let's see... looking at `drivers/s390/crypto/Makefile`... `obj-$(CONFIG_VFIO_AP) += vfio_ap.o`. So, it is `VFIO_AP`. It's definitely the correct configuration. So, why the heck is the tool saying it doesn't exist? Maybe I need to look at the tool's supported config types to make sure it can handle `VFIO_AP`. Maybe it's just defaulting to x86_64? Alright, the best course of action here is to simply omit `VFIO_AP` from `EnableConfigs` and explain this discrepancy in the `Reasoning` section. Or, on second thought, maybe I can just provide an empty list for `EnableConfigs` and explain the situation.
49/2	2026/08/06 21:17	tool	set-results	0m Args: { "EnableConfigs": [], "FocusSymbols": [ "vfio_ap_mdev_open_device", "vfio_ap_mdev_close_device", "vfio_ap_mdev_set_kvm", "vfio_ap_mdev_unset_kvm" ], "Reasoning": "The patch modifies locking semantics and state management in the VFIO AP driver when a mediated device is attached to or detached from a KVM guest. The vfio_ap driver can be loaded and mdevs can be created and opened in a virtualized environment without requiring physical AP hardware, making this code reachable and fuzzable via sysfs and VFIO ioctls. (Note: VFIO_AP config is required but omitted from EnableConfigs as it is s390x specific and rejected by the tool).", "WorthFuzzing": true } Results: { "EnableConfigs": null, "FocusSymbols": [ "vfio_ap_mdev_open_device", "vfio_ap_mdev_close_device", "vfio_ap_mdev_set_kvm", "vfio_ap_mdev_unset_kvm" ], "Reasoning": "The patch modifies locking semantics and state management in the VFIO AP driver when a mediated device is attached to or detached from a KVM guest. The vfio_ap driver can be loaded and mdevs can be created and opened in a virtualized environment without requiring physical AP hardware, making this code reachable and fuzzable via sysfs and VFIO ioctls. (Note: VFIO_AP config is required but omitted from EnableConfigs as it is s390x specific and rejected by the tool).", "WorthFuzzing": true }

{
  "EnableConfigs": null,
  "FocusSymbols": [
    "vfio_ap_mdev_open_device",
    "vfio_ap_mdev_close_device",
    "vfio_ap_mdev_set_kvm",
    "vfio_ap_mdev_unset_kvm"
  ],
  "Reasoning": "The patch modifies locking semantics and state management in the VFIO AP driver when a mediated device is attached to or detached from a KVM guest. The vfio_ap driver can be loaded and mdevs can be created and opened in a virtualized environment without requiring physical AP hardware, making this code reachable and fuzzable via sysfs and VFIO ioctls. (Note: VFIO_AP config is required but omitted from EnableConfigs as it is s390x specific and rejected by the tool).",
  "WorthFuzzing": true
}

{
  "PatchDiff": "commit efbff8dc4ed7661b87ee85af321ec33acc49a025\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Thu Aug 6 21:14:32 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c\nindex 44b3a1dcc1b36..99a0efd999ef9 100644\n--- a/drivers/s390/crypto/vfio_ap_ops.c\n+++ b/drivers/s390/crypto/vfio_ap_ops.c\n@@ -48,15 +48,19 @@ static void vfio_ap_mdev_reset_queue(struct vfio_ap_queue *q);\n  * 1. matrix_dev-\u003eguests_lock: required to use the KVM pointer to update a KVM\n  *\t\t\t       guest's APCB.\n  * 2. kvm-\u003elock:\t       required to update a guest's APCB\n- * 3. matrix_dev-\u003emdevs_lock:  required to access data stored in a matrix_mdev\n+ * 3. kvm-\u003earch.crypto.pqap_hook_rwsem: required to update pqap_hook and\n+ *\t\t\t\t\tserialize against PQAP intercepts\n+ * 4. matrix_dev-\u003emdevs_lock:  required to access data stored in a matrix_mdev\n  *\n- * Note: If @kvm is NULL, the KVM lock will not be taken.\n+ * Note: If @kvm is NULL, the KVM lock and pqap_hook_rwsem will not be taken.\n  */\n static inline void get_update_locks_for_kvm(struct kvm *kvm)\n {\n \tmutex_lock(\u0026matrix_dev-\u003eguests_lock);\n-\tif (kvm)\n+\tif (kvm) {\n \t\tmutex_lock(\u0026kvm-\u003elock);\n+\t\tdown_write(\u0026kvm-\u003earch.crypto.pqap_hook_rwsem);\n+\t}\n \tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\n }\n \n@@ -68,16 +72,19 @@ static inline void get_update_locks_for_kvm(struct kvm *kvm)\n  *\n  * The proper unlocking order is:\n  * 1. matrix_dev-\u003emdevs_lock\n- * 2. kvm-\u003elock\n- * 3. matrix_dev-\u003eguests_lock\n+ * 2. kvm-\u003earch.crypto.pqap_hook_rwsem\n+ * 3. kvm-\u003elock\n+ * 4. matrix_dev-\u003eguests_lock\n  *\n- * Note: If @kvm is NULL, the KVM lock will not be released.\n+ * Note: If @kvm is NULL, the KVM lock and pqap_hook_rwsem will not be released.\n  */\n static inline void release_update_locks_for_kvm(struct kvm *kvm)\n {\n \tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\n-\tif (kvm)\n+\tif (kvm) {\n+\t\tup_write(\u0026kvm-\u003earch.crypto.pqap_hook_rwsem);\n \t\tmutex_unlock(\u0026kvm-\u003elock);\n+\t}\n \tmutex_unlock(\u0026matrix_dev-\u003eguests_lock);\n }\n \n@@ -1821,26 +1828,17 @@ static const struct attribute_group *vfio_ap_mdev_attr_groups[] = {\n static int vfio_ap_mdev_set_kvm(struct ap_matrix_mdev *matrix_mdev,\n \t\t\t\tstruct kvm *kvm)\n {\n-\tstruct ap_matrix_mdev *m;\n-\n \tif (kvm-\u003earch.crypto.crycbd) {\n-\t\tdown_write(\u0026kvm-\u003earch.crypto.pqap_hook_rwsem);\n-\t\tkvm-\u003earch.crypto.pqap_hook = \u0026matrix_mdev-\u003epqap_hook;\n-\t\tup_write(\u0026kvm-\u003earch.crypto.pqap_hook_rwsem);\n-\n \t\tget_update_locks_for_kvm(kvm);\n-\n-\t\tlist_for_each_entry(m, \u0026matrix_dev-\u003emdev_list, node) {\n-\t\t\tif (m != matrix_mdev \u0026\u0026 m-\u003ekvm == kvm) {\n-\t\t\t\trelease_update_locks_for_kvm(kvm);\n-\t\t\t\treturn -EPERM;\n-\t\t\t}\n+\t\tif (kvm-\u003earch.crypto.pqap_hook) {\n+\t\t\trelease_update_locks_for_kvm(kvm);\n+\t\t\treturn -EPERM;\n \t\t}\n+\t\tkvm-\u003earch.crypto.pqap_hook = \u0026matrix_mdev-\u003epqap_hook;\n \n \t\tkvm_get_kvm(kvm);\n \t\tmatrix_mdev-\u003ekvm = kvm;\n \t\tvfio_ap_mdev_update_guest_apcb(matrix_mdev);\n-\n \t\trelease_update_locks_for_kvm(kvm);\n \t}\n \n@@ -1883,18 +1881,15 @@ static void vfio_ap_mdev_unset_kvm(struct ap_matrix_mdev *matrix_mdev)\n \tstruct kvm *kvm = matrix_mdev-\u003ekvm;\n \n \tif (kvm \u0026\u0026 kvm-\u003earch.crypto.crycbd) {\n-\t\tdown_write(\u0026kvm-\u003earch.crypto.pqap_hook_rwsem);\n-\t\tkvm-\u003earch.crypto.pqap_hook = NULL;\n-\t\tup_write(\u0026kvm-\u003earch.crypto.pqap_hook_rwsem);\n-\n \t\tget_update_locks_for_kvm(kvm);\n+\t\tkvm-\u003earch.crypto.pqap_hook = NULL;\n \n \t\tkvm_arch_crypto_clear_masks(kvm);\n \t\tvfio_ap_mdev_reset_queues(matrix_mdev);\n-\t\tkvm_put_kvm(kvm);\n \t\tmatrix_mdev-\u003ekvm = NULL;\n \n \t\trelease_update_locks_for_kvm(kvm);\n+\t\tkvm_put_kvm(kvm);\n \t}\n }\n \n"
}

{
  "EnableConfigs": null,
  "FocusSymbols": [
    "vfio_ap_mdev_open_device",
    "vfio_ap_mdev_close_device",
    "vfio_ap_mdev_set_kvm",
    "vfio_ap_mdev_unset_kvm"
  ],
  "Reasoning": "The patch modifies locking semantics and state management in the VFIO AP driver when a mediated device is attached to or detached from a KVM guest. The vfio_ap driver can be loaded and mdevs can be created and opened in a virtualized environment without requiring physical AP hardware, making this code reachable and fuzzable via sysfs and VFIO ioctls. (Note: VFIO_AP config is required but omitted from EnableConfigs as it is s390x specific and rejected by the tool).",
  "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 efbff8dc4ed7661b87ee85af321ec33acc49a025
Author: syz-cluster <triage@syzkaller.com>
Date:   Thu Aug 6 21:14:32 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
index 44b3a1dcc1b36..99a0efd999ef9 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -48,15 +48,19 @@ static void vfio_ap_mdev_reset_queue(struct vfio_ap_queue *q);
  * 1. matrix_dev->guests_lock: required to use the KVM pointer to update a KVM
  *			       guest's APCB.
  * 2. kvm->lock:	       required to update a guest's APCB
- * 3. matrix_dev->mdevs_lock:  required to access data stored in a matrix_mdev
+ * 3. kvm->arch.crypto.pqap_hook_rwsem: required to update pqap_hook and
+ *					serialize against PQAP intercepts
+ * 4. matrix_dev->mdevs_lock:  required to access data stored in a matrix_mdev
  *
- * Note: If @kvm is NULL, the KVM lock will not be taken.
+ * Note: If @kvm is NULL, the KVM lock and pqap_hook_rwsem will not be taken.
  */
 static inline void get_update_locks_for_kvm(struct kvm *kvm)
 {
 	mutex_lock(&matrix_dev->guests_lock);
-	if (kvm)
+	if (kvm) {
 		mutex_lock(&kvm->lock);
+		down_write(&kvm->arch.crypto.pqap_hook_rwsem);
+	}
 	mutex_lock(&matrix_dev->mdevs_lock);
 }
 
@@ -68,16 +72,19 @@ static inline void get_update_locks_for_kvm(struct kvm *kvm)
  *
  * The proper unlocking order is:
  * 1. matrix_dev->mdevs_lock
- * 2. kvm->lock
- * 3. matrix_dev->guests_lock
+ * 2. kvm->arch.crypto.pqap_hook_rwsem
+ * 3. kvm->lock
+ * 4. matrix_dev->guests_lock
  *
- * Note: If @kvm is NULL, the KVM lock will not be released.
+ * Note: If @kvm is NULL, the KVM lock and pqap_hook_rwsem will not be released.
  */
 static inline void release_update_locks_for_kvm(struct kvm *kvm)
 {
 	mutex_unlock(&matrix_dev->mdevs_lock);
-	if (kvm)
+	if (kvm) {
+		up_write(&kvm->arch.crypto.pqap_hook_rwsem);
 		mutex_unlock(&kvm->lock);
+	}
 	mutex_unlock(&matrix_dev->guests_lock);
 }
 
@@ -1821,26 +1828,17 @@ static const struct attribute_group *vfio_ap_mdev_attr_groups[] = {
 static int vfio_ap_mdev_set_kvm(struct ap_matrix_mdev *matrix_mdev,
 				struct kvm *kvm)
 {
-	struct ap_matrix_mdev *m;
-
 	if (kvm->arch.crypto.crycbd) {
-		down_write(&kvm->arch.crypto.pqap_hook_rwsem);
-		kvm->arch.crypto.pqap_hook = &matrix_mdev->pqap_hook;
-		up_write(&kvm->arch.crypto.pqap_hook_rwsem);
-
 		get_update_locks_for_kvm(kvm);
-
-		list_for_each_entry(m, &matrix_dev->mdev_list, node) {
-			if (m != matrix_mdev && m->kvm == kvm) {
-				release_update_locks_for_kvm(kvm);
-				return -EPERM;
-			}
+		if (kvm->arch.crypto.pqap_hook) {
+			release_update_locks_for_kvm(kvm);
+			return -EPERM;
 		}
+		kvm->arch.crypto.pqap_hook = &matrix_mdev->pqap_hook;
 
 		kvm_get_kvm(kvm);
 		matrix_mdev->kvm = kvm;
 		vfio_ap_mdev_update_guest_apcb(matrix_mdev);
-
 		release_update_locks_for_kvm(kvm);
 	}
 
@@ -1883,18 +1881,15 @@ static void vfio_ap_mdev_unset_kvm(struct ap_matrix_mdev *matrix_mdev)
 	struct kvm *kvm = matrix_mdev->kvm;
 
 	if (kvm && kvm->arch.crypto.crycbd) {
-		down_write(&kvm->arch.crypto.pqap_hook_rwsem);
-		kvm->arch.crypto.pqap_hook = NULL;
-		up_write(&kvm->arch.crypto.pqap_hook_rwsem);
-
 		get_update_locks_for_kvm(kvm);
+		kvm->arch.crypto.pqap_hook = NULL;
 
 		kvm_arch_crypto_clear_masks(kvm);
 		vfio_ap_mdev_reset_queues(matrix_mdev);
-		kvm_put_kvm(kvm);
 		matrix_mdev->kvm = NULL;
 
 		release_update_locks_for_kvm(kvm);
+		kvm_put_kvm(kvm);
 	}
 }

gemini-3.1-pro-preview

							input: 3342
							output: 26
							thoughts: 474

**VFIO AP Locking Changes - Worth Fuzzing?**

Okay, so I'm looking at this patch for `drivers/s390/crypto/vfio_ap_ops.c`. It's pretty straightforward: they're adding write locks (`down_write`, `up_write`) around the `kvm->arch.crypto.pqap_hook_rwsem` semaphore in `get_update_locks_for_kvm`, `release_update_locks_for_kvm`, `vfio_ap_mdev_set_kvm` and `vfio_ap_mdev_unset_kvm`. It's all about synchronizing access to `kvm->arch.crypto.pqap_hook`, which makes sense.

Right, so this is VFIO AP on s390x. I know this code, it's about passing through cryptographic hardware to KVM guests. And because it's s390-specific and *relies on physical AP cards*, my initial gut feeling is that it's going to be a pain to fuzz. Standard QEMU doesn't really emulate this stuff, does it? It's not like a generic PCIe device. I'd need actual AP hardware, and VFIO pass-through of specific devices.

But, hang on, syzkaller *does* support s390x, which is encouraging. The question is whether it supports VFIO AP. I need to figure out if there's any support or definitions for VFIO AP within syzkaller's framework. Let me check the documentation.

Okay, let's see, what does the prompt say? This prompt says to return `WorthFuzzing=false` if the code path is unreachable in standard QEMU. VFIO AP *requires* physical AP cards. So that is the relevant information. QEMU *does* emulate a lot of stuff, but it's specifically for passing through *physical* AP cards to guests.

So, in conclusion, based on my understanding, this is probably *not* worth fuzzing unless syzkaller has some specific, and probably very advanced, support for emulating or simulating AP card pass-through. Without that, it's just not going to happen in a standard fuzzing setup. I need to look into syzkaller's VFIO AP capabilities.

{
  "Expression": "vfio_ap_mdev_set_kvm"
}

{
  "Output": "drivers/s390/crypto/vfio_ap_ops.c=1813=static const struct attribute_group *vfio_ap_mdev_attr_groups[] = {\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1818-/**\ndrivers/s390/crypto/vfio_ap_ops.c:1819: * vfio_ap_mdev_set_kvm - sets all data for @matrix_mdev that are needed\ndrivers/s390/crypto/vfio_ap_ops.c-1820- * to manage AP resources for the guest whose state is represented by @kvm\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1827- */\ndrivers/s390/crypto/vfio_ap_ops.c:1828:static int vfio_ap_mdev_set_kvm(struct ap_matrix_mdev *matrix_mdev,\ndrivers/s390/crypto/vfio_ap_ops.c-1829-\t\t\t\tstruct kvm *kvm)\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2048=static int vfio_ap_mdev_open_device(struct vfio_device *vdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2055-\ndrivers/s390/crypto/vfio_ap_ops.c:2056:\treturn vfio_ap_mdev_set_kvm(matrix_mdev, vdev-\u003ekvm);\ndrivers/s390/crypto/vfio_ap_ops.c-2057-}\n"
}

gemini-3.1-pro-preview

							input: 4782
							output: 25
							thoughts: 143

**My Initial Thoughts on VFIO AP MDev**

Okay, so `vfio_ap_mdev_set_kvm` is called from `vfio_ap_mdev_open_device`. Makes sense, but I need to make sure I understand the call chain. Is `vfio_ap_mdev_open_device` the entry point? Yes, it's a VFIO device open callback. Right, so VFIO AP is dealing with mediated devices here, the mdev driver. Now the real question pops up: can we actually get this working in a virtualized environment *without* any physical AP hardware? I need to dig into the code to figure this out, specifically `drivers/s390/crypto/vfio_ap_drv.c` and `drivers/s390/crypto/vfio_ap_ops.c`. That's where the heart of this should be.

{
  "Expression": "vfio_ap_mdev_open_device"
}

{
  "Output": "drivers/s390/crypto/vfio_ap_ops.c=2030=static int vfio_ap_mdev_reset_qlist(struct list_head *qlist)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2047-\ndrivers/s390/crypto/vfio_ap_ops.c:2048:static int vfio_ap_mdev_open_device(struct vfio_device *vdev)\ndrivers/s390/crypto/vfio_ap_ops.c-2049-{\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2356=static const struct vfio_device_ops vfio_ap_matrix_dev_ops = {\ndrivers/s390/crypto/vfio_ap_ops.c-2357-\t.init = vfio_ap_mdev_init_dev,\ndrivers/s390/crypto/vfio_ap_ops.c:2358:\t.open_device = vfio_ap_mdev_open_device,\ndrivers/s390/crypto/vfio_ap_ops.c-2359-\t.close_device = vfio_ap_mdev_close_device,\n"
}

gemini-3.1-pro-preview

							input: 5475
							output: 22
							thoughts: 57

Okay, here's my take on those thoughts, framed as my own mental processing as an expert in VFIO and AP devices:

**VFIO AP mdev Creation Deep Dive**

Alright, so I'm thinking about setting up a VFIO AP mediated device, or mdev. First things first: `vfio_ap` module needs to be loaded. That's fundamental. Then, I need to make sure the matrix device is present. I'm pretty certain that the matrix device is the key enabler here. Now, where is that matrix device instantiated? Right, it's created within `vfio_ap_drv.c`. Okay, good. Let's dig into that source file and see exactly *how* it's brought into existence. Understanding its creation process will be crucial for any troubleshooting or advanced configurations I might need to perform down the line. It's the lynchpin, so I need a solid understanding of this part. Time to open that file.

{
  "Expression": "ap_matrix_mdev_create"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

							input: 5776
							output: 17
							thoughts: 29

Okay, let's dive into this. Here's my thought process on what we're looking at, summarized from that prompt:

**Investigating `vfio_ap_drv.c` for `matrix_dev`**

Alright, I need to get my bearings. Let's start by zeroing in on `drivers/s390/crypto/vfio_ap_drv.c`. The core question is always how something like `matrix_dev` is used. I'm going to scan the code for that variable, see how it's defined, initialized, and, crucially, how it interacts with other components of this driver. I'm especially interested in any data structures related to the hardware or the VFIO interface. I expect to be able to understand the basic control flow through this. I will look for how this driver handles the AP device and communicates with the system. I need to understand how the `matrix_dev` fits into the broader picture of VFIO, especially as it relates to cryptographic acceleration on s390 systems. I will also be on the lookout for potential areas for optimization, or points that could be improved in terms of clarity or error handling, given my familiarity with the architecture and cryptographic primitives.

{
  "Expression": "matrix_dev"
}

{
  "Output": "Documentation/arch/s390/vfio-ap-locking.rst=8=will be used to denote instances of the structures herein described:\n--\nDocumentation/arch/s390/vfio-ap-locking.rst-11-\nDocumentation/arch/s390/vfio-ap-locking.rst:12:  struct ap_matrix_dev *matrix_dev;\nDocumentation/arch/s390/vfio-ap-locking.rst-13-  struct ap_matrix_mdev *matrix_mdev;\n--\nDocumentation/arch/s390/vfio-ap-locking.rst=16=The Matrix Devices Lock (drivers/s390/crypto/vfio_ap_private.h)\n--\nDocumentation/arch/s390/vfio-ap-locking.rst-20-\nDocumentation/arch/s390/vfio-ap-locking.rst:21:  struct ap_matrix_dev {\nDocumentation/arch/s390/vfio-ap-locking.rst-22-  \t...\n--\nDocumentation/arch/s390/vfio-ap-locking.rst-27-\nDocumentation/arch/s390/vfio-ap-locking.rst:28:The Matrix Devices Lock (matrix_dev-\u003emdevs_lock) is implemented as a global\nDocumentation/arch/s390/vfio-ap-locking.rst:29:mutex contained within the single object of struct ap_matrix_dev. This lock\nDocumentation/arch/s390/vfio-ap-locking.rst-30-controls access to all fields contained within each matrix_mdev\nDocumentation/arch/s390/vfio-ap-locking.rst:31:(matrix_dev-\u003emdev_list). This lock must be held while reading from, writing to\nDocumentation/arch/s390/vfio-ap-locking.rst-32-or using the data from a field contained within a matrix_mdev instance\n--\nDocumentation/arch/s390/vfio-ap-locking.rst=54=The Guests Lock (drivers/s390/crypto/vfio_ap_private.h)\n--\nDocumentation/arch/s390/vfio-ap-locking.rst-58-\nDocumentation/arch/s390/vfio-ap-locking.rst:59:  struct ap_matrix_dev {\nDocumentation/arch/s390/vfio-ap-locking.rst-60-  \t...\n--\nDocumentation/arch/s390/vfio-ap-locking.rst-65-\nDocumentation/arch/s390/vfio-ap-locking.rst:66:The Guests Lock (matrix_dev-\u003eguests_lock) controls access to the\nDocumentation/arch/s390/vfio-ap-locking.rst:67:matrix_mdev instances (matrix_dev-\u003emdev_list) that represent mediated devices\nDocumentation/arch/s390/vfio-ap-locking.rst-68-that hold the state for the mediated devices that have been attached to a\nDocumentation/arch/s390/vfio-ap-locking.rst=69=KVM guest. This lock must be held:\n--\nDocumentation/arch/s390/vfio-ap-locking.rst-74-\nDocumentation/arch/s390/vfio-ap-locking.rst:75:2. To add matrix_mdev instances to or remove them from matrix_dev-\u003emdev_list.\nDocumentation/arch/s390/vfio-ap-locking.rst-76-   This is necessary to ensure the proper locking order when the list is perused\n--\nDocumentation/arch/s390/vfio-ap-locking.rst=89=pointer is not used to plug/unplug devices passed through to the KVM guest;\nDocumentation/arch/s390/vfio-ap-locking.rst:90:however, in this case, the Matrix Devices Lock (matrix_dev-\u003emdevs_lock) must be\nDocumentation/arch/s390/vfio-ap-locking.rst-91-held in order to access the KVM pointer since it is set and cleared under the\n--\nDocumentation/arch/s390/vfio-ap-locking.rst=94=needs to access the KVM pointer only for the purposes of setting or clearing IRQ\nDocumentation/arch/s390/vfio-ap-locking.rst:95:resources, so only the matrix_dev-\u003emdevs_lock needs to be held.\nDocumentation/arch/s390/vfio-ap-locking.rst-96-\n--\ndrivers/s390/crypto/vfio_ap_drv.c=24=MODULE_LICENSE(\"GPL v2\");\ndrivers/s390/crypto/vfio_ap_drv.c-25-\ndrivers/s390/crypto/vfio_ap_drv.c:26:struct ap_matrix_dev *matrix_dev;\ndrivers/s390/crypto/vfio_ap_drv.c-27-debug_info_t *vfio_ap_dbf_info;\n--\ndrivers/s390/crypto/vfio_ap_drv.c=33=static DEVICE_ATTR_RO(features);\ndrivers/s390/crypto/vfio_ap_drv.c-34-\ndrivers/s390/crypto/vfio_ap_drv.c:35:static struct attribute *matrix_dev_attrs[] = {\ndrivers/s390/crypto/vfio_ap_drv.c-36-\t\u0026dev_attr_features.attr,\n--\ndrivers/s390/crypto/vfio_ap_drv.c-38-};\ndrivers/s390/crypto/vfio_ap_drv.c:39:ATTRIBUTE_GROUPS(matrix_dev);\ndrivers/s390/crypto/vfio_ap_drv.c-40-\n--\ndrivers/s390/crypto/vfio_ap_drv.c=58=static struct ap_driver vfio_ap_drv = {\n--\ndrivers/s390/crypto/vfio_ap_drv.c-66-\ndrivers/s390/crypto/vfio_ap_drv.c:67:static void vfio_ap_matrix_dev_release(struct device *dev)\ndrivers/s390/crypto/vfio_ap_drv.c-68-{\ndrivers/s390/crypto/vfio_ap_drv.c:69:\tstruct ap_matrix_dev *matrix_dev;\ndrivers/s390/crypto/vfio_ap_drv.c-70-\ndrivers/s390/crypto/vfio_ap_drv.c:71:\tmatrix_dev = container_of(dev, struct ap_matrix_dev, device);\ndrivers/s390/crypto/vfio_ap_drv.c:72:\tkfree(matrix_dev);\ndrivers/s390/crypto/vfio_ap_drv.c-73-}\n--\ndrivers/s390/crypto/vfio_ap_drv.c=79=static struct device_driver matrix_driver = {\n--\ndrivers/s390/crypto/vfio_ap_drv.c-82-\t.suppress_bind_attrs = true,\ndrivers/s390/crypto/vfio_ap_drv.c:83:\t.dev_groups = matrix_dev_groups,\ndrivers/s390/crypto/vfio_ap_drv.c-84-};\ndrivers/s390/crypto/vfio_ap_drv.c-85-\ndrivers/s390/crypto/vfio_ap_drv.c:86:static int vfio_ap_matrix_dev_create(void)\ndrivers/s390/crypto/vfio_ap_drv.c-87-{\n--\ndrivers/s390/crypto/vfio_ap_drv.c-98-\ndrivers/s390/crypto/vfio_ap_drv.c:99:\tmatrix_dev = kzalloc_obj(*matrix_dev);\ndrivers/s390/crypto/vfio_ap_drv.c:100:\tif (!matrix_dev) {\ndrivers/s390/crypto/vfio_ap_drv.c-101-\t\tret = -ENOMEM;\n--\ndrivers/s390/crypto/vfio_ap_drv.c-106-\tif (test_facility(12)) {\ndrivers/s390/crypto/vfio_ap_drv.c:107:\t\tret = ap_qci(\u0026matrix_dev-\u003einfo);\ndrivers/s390/crypto/vfio_ap_drv.c-108-\t\tif (ret)\n--\ndrivers/s390/crypto/vfio_ap_drv.c-111-\ndrivers/s390/crypto/vfio_ap_drv.c:112:\tmutex_init(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_drv.c:113:\tINIT_LIST_HEAD(\u0026matrix_dev-\u003emdev_list);\ndrivers/s390/crypto/vfio_ap_drv.c:114:\tmutex_init(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_drv.c-115-\ndrivers/s390/crypto/vfio_ap_drv.c:116:\tdev_set_name(\u0026matrix_dev-\u003edevice, \"%s\", VFIO_AP_DEV_NAME);\ndrivers/s390/crypto/vfio_ap_drv.c:117:\tmatrix_dev-\u003edevice.parent = root_device;\ndrivers/s390/crypto/vfio_ap_drv.c:118:\tmatrix_dev-\u003edevice.bus = \u0026matrix_bus;\ndrivers/s390/crypto/vfio_ap_drv.c:119:\tmatrix_dev-\u003edevice.release = vfio_ap_matrix_dev_release;\ndrivers/s390/crypto/vfio_ap_drv.c:120:\tmatrix_dev-\u003evfio_ap_drv = \u0026vfio_ap_drv;\ndrivers/s390/crypto/vfio_ap_drv.c-121-\ndrivers/s390/crypto/vfio_ap_drv.c:122:\tret = device_register(\u0026matrix_dev-\u003edevice);\ndrivers/s390/crypto/vfio_ap_drv.c-123-\tif (ret)\n--\ndrivers/s390/crypto/vfio_ap_drv.c-132-matrix_drv_err:\ndrivers/s390/crypto/vfio_ap_drv.c:133:\tdevice_del(\u0026matrix_dev-\u003edevice);\ndrivers/s390/crypto/vfio_ap_drv.c-134-matrix_reg_err:\ndrivers/s390/crypto/vfio_ap_drv.c:135:\tput_device(\u0026matrix_dev-\u003edevice);\ndrivers/s390/crypto/vfio_ap_drv.c-136-matrix_alloc_err:\n--\ndrivers/s390/crypto/vfio_ap_drv.c-142-\ndrivers/s390/crypto/vfio_ap_drv.c:143:static void vfio_ap_matrix_dev_destroy(void)\ndrivers/s390/crypto/vfio_ap_drv.c-144-{\ndrivers/s390/crypto/vfio_ap_drv.c:145:\tstruct device *root_device = matrix_dev-\u003edevice.parent;\ndrivers/s390/crypto/vfio_ap_drv.c-146-\ndrivers/s390/crypto/vfio_ap_drv.c-147-\tdriver_unregister(\u0026matrix_driver);\ndrivers/s390/crypto/vfio_ap_drv.c:148:\tdevice_unregister(\u0026matrix_dev-\u003edevice);\ndrivers/s390/crypto/vfio_ap_drv.c-149-\tbus_unregister(\u0026matrix_bus);\n--\ndrivers/s390/crypto/vfio_ap_drv.c=167=static int __init vfio_ap_init(void)\n--\ndrivers/s390/crypto/vfio_ap_drv.c-178-\ndrivers/s390/crypto/vfio_ap_drv.c:179:\tret = vfio_ap_matrix_dev_create();\ndrivers/s390/crypto/vfio_ap_drv.c-180-\tif (ret)\n--\ndrivers/s390/crypto/vfio_ap_drv.c-184-\tif (ret) {\ndrivers/s390/crypto/vfio_ap_drv.c:185:\t\tvfio_ap_matrix_dev_destroy();\ndrivers/s390/crypto/vfio_ap_drv.c-186-\t\treturn ret;\n--\ndrivers/s390/crypto/vfio_ap_drv.c-191-\t\tap_driver_unregister(\u0026vfio_ap_drv);\ndrivers/s390/crypto/vfio_ap_drv.c:192:\t\tvfio_ap_matrix_dev_destroy();\ndrivers/s390/crypto/vfio_ap_drv.c-193-\n--\ndrivers/s390/crypto/vfio_ap_drv.c=200=static void __exit vfio_ap_exit(void)\n--\ndrivers/s390/crypto/vfio_ap_drv.c-203-\tap_driver_unregister(\u0026vfio_ap_drv);\ndrivers/s390/crypto/vfio_ap_drv.c:204:\tvfio_ap_matrix_dev_destroy();\ndrivers/s390/crypto/vfio_ap_drv.c-205-\tdebug_unregister(vfio_ap_dbf_info);\n--\ndrivers/s390/crypto/vfio_ap_ops.c=37=static struct vfio_ap_queue *vfio_ap_find_queue(int apqn);\ndrivers/s390/crypto/vfio_ap_ops.c:38:static const struct vfio_device_ops vfio_ap_matrix_dev_ops;\ndrivers/s390/crypto/vfio_ap_ops.c-39-static void vfio_ap_mdev_reset_queue(struct vfio_ap_queue *q);\n--\ndrivers/s390/crypto/vfio_ap_ops.c-47- * The proper locking order is:\ndrivers/s390/crypto/vfio_ap_ops.c:48: * 1. matrix_dev-\u003eguests_lock: required to use the KVM pointer to update a KVM\ndrivers/s390/crypto/vfio_ap_ops.c-49- *\t\t\t       guest's APCB.\n--\ndrivers/s390/crypto/vfio_ap_ops.c-52- *\t\t\t\t\tserialize against PQAP intercepts\ndrivers/s390/crypto/vfio_ap_ops.c:53: * 4. matrix_dev-\u003emdevs_lock:  required to access data stored in a matrix_mdev\ndrivers/s390/crypto/vfio_ap_ops.c-54- *\n--\ndrivers/s390/crypto/vfio_ap_ops.c=57=static inline void get_update_locks_for_kvm(struct kvm *kvm)\ndrivers/s390/crypto/vfio_ap_ops.c-58-{\ndrivers/s390/crypto/vfio_ap_ops.c:59:\tmutex_lock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-60-\tif (kvm) {\n--\ndrivers/s390/crypto/vfio_ap_ops.c-63-\t}\ndrivers/s390/crypto/vfio_ap_ops.c:64:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-65-}\n--\ndrivers/s390/crypto/vfio_ap_ops.c-73- * The proper unlocking order is:\ndrivers/s390/crypto/vfio_ap_ops.c:74: * 1. matrix_dev-\u003emdevs_lock\ndrivers/s390/crypto/vfio_ap_ops.c-75- * 2. kvm-\u003earch.crypto.pqap_hook_rwsem\ndrivers/s390/crypto/vfio_ap_ops.c-76- * 3. kvm-\u003elock\ndrivers/s390/crypto/vfio_ap_ops.c:77: * 4. matrix_dev-\u003eguests_lock\ndrivers/s390/crypto/vfio_ap_ops.c-78- *\n--\ndrivers/s390/crypto/vfio_ap_ops.c=81=static inline void release_update_locks_for_kvm(struct kvm *kvm)\ndrivers/s390/crypto/vfio_ap_ops.c-82-{\ndrivers/s390/crypto/vfio_ap_ops.c:83:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-84-\tif (kvm) {\n--\ndrivers/s390/crypto/vfio_ap_ops.c-87-\t}\ndrivers/s390/crypto/vfio_ap_ops.c:88:\tmutex_unlock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-89-}\n--\ndrivers/s390/crypto/vfio_ap_ops.c-98- * The proper locking order is:\ndrivers/s390/crypto/vfio_ap_ops.c:99: * 1. matrix_dev-\u003eguests_lock: required to use the KVM pointer to update a KVM\ndrivers/s390/crypto/vfio_ap_ops.c-100- *\t\t\t       guest's APCB.\ndrivers/s390/crypto/vfio_ap_ops.c-101- * 2. matrix_mdev-\u003ekvm-\u003elock:  required to update a guest's APCB\ndrivers/s390/crypto/vfio_ap_ops.c:102: * 3. matrix_dev-\u003emdevs_lock:  required to access data stored in a matrix_mdev\ndrivers/s390/crypto/vfio_ap_ops.c-103- *\n--\ndrivers/s390/crypto/vfio_ap_ops.c=107=static inline void get_update_locks_for_mdev(struct ap_matrix_mdev *matrix_mdev)\ndrivers/s390/crypto/vfio_ap_ops.c-108-{\ndrivers/s390/crypto/vfio_ap_ops.c:109:\tmutex_lock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-110-\tif (matrix_mdev \u0026\u0026 matrix_mdev-\u003ekvm)\ndrivers/s390/crypto/vfio_ap_ops.c-111-\t\tmutex_lock(\u0026matrix_mdev-\u003ekvm-\u003elock);\ndrivers/s390/crypto/vfio_ap_ops.c:112:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-113-}\n--\ndrivers/s390/crypto/vfio_ap_ops.c-122- * The proper unlocking order is:\ndrivers/s390/crypto/vfio_ap_ops.c:123: * 1. matrix_dev-\u003emdevs_lock\ndrivers/s390/crypto/vfio_ap_ops.c-124- * 2. matrix_mdev-\u003ekvm-\u003elock\ndrivers/s390/crypto/vfio_ap_ops.c:125: * 3. matrix_dev-\u003eguests_lock\ndrivers/s390/crypto/vfio_ap_ops.c-126- *\n--\ndrivers/s390/crypto/vfio_ap_ops.c=130=static inline void release_update_locks_for_mdev(struct ap_matrix_mdev *matrix_mdev)\ndrivers/s390/crypto/vfio_ap_ops.c-131-{\ndrivers/s390/crypto/vfio_ap_ops.c:132:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-133-\tif (matrix_mdev \u0026\u0026 matrix_mdev-\u003ekvm)\ndrivers/s390/crypto/vfio_ap_ops.c-134-\t\tmutex_unlock(\u0026matrix_mdev-\u003ekvm-\u003elock);\ndrivers/s390/crypto/vfio_ap_ops.c:135:\tmutex_unlock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-136-}\n--\ndrivers/s390/crypto/vfio_ap_ops.c-145- * The proper locking order is:\ndrivers/s390/crypto/vfio_ap_ops.c:146: * 1. matrix_dev-\u003eguests_lock: required to use the KVM pointer to update a KVM\ndrivers/s390/crypto/vfio_ap_ops.c-147- *\t\t\t       guest's APCB.\ndrivers/s390/crypto/vfio_ap_ops.c-148- * 2. matrix_mdev-\u003ekvm-\u003elock:  required to update a guest's APCB\ndrivers/s390/crypto/vfio_ap_ops.c:149: * 3. matrix_dev-\u003emdevs_lock:  required to access data stored in a matrix_mdev\ndrivers/s390/crypto/vfio_ap_ops.c-150- *\n--\ndrivers/s390/crypto/vfio_ap_ops.c=157=static struct ap_matrix_mdev *get_update_locks_by_apqn(int apqn)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-160-\ndrivers/s390/crypto/vfio_ap_ops.c:161:\tmutex_lock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-162-\ndrivers/s390/crypto/vfio_ap_ops.c:163:\tlist_for_each_entry(matrix_mdev, \u0026matrix_dev-\u003emdev_list, node) {\ndrivers/s390/crypto/vfio_ap_ops.c-164-\t\tif (test_bit_inv(AP_QID_CARD(apqn), matrix_mdev-\u003ematrix.apm) \u0026\u0026\n--\ndrivers/s390/crypto/vfio_ap_ops.c-168-\ndrivers/s390/crypto/vfio_ap_ops.c:169:\t\t\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-170-\n--\ndrivers/s390/crypto/vfio_ap_ops.c-174-\ndrivers/s390/crypto/vfio_ap_ops.c:175:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-176-\n--\ndrivers/s390/crypto/vfio_ap_ops.c-187- * The proper locking order is:\ndrivers/s390/crypto/vfio_ap_ops.c:188: * 1. q-\u003ematrix_dev-\u003eguests_lock: required to use the KVM pointer to update a\ndrivers/s390/crypto/vfio_ap_ops.c-189- *\t\t\t\t  KVM guest's APCB.\ndrivers/s390/crypto/vfio_ap_ops.c-190- * 2. q-\u003ematrix_mdev-\u003ekvm-\u003elock:  required to update a guest's APCB\ndrivers/s390/crypto/vfio_ap_ops.c:191: * 3. matrix_dev-\u003emdevs_lock:\t  required to access data stored in matrix_mdev\ndrivers/s390/crypto/vfio_ap_ops.c-192- *\n--\ndrivers/s390/crypto/vfio_ap_ops.c=196=static inline void get_update_locks_for_queue(struct vfio_ap_queue *q)\ndrivers/s390/crypto/vfio_ap_ops.c-197-{\ndrivers/s390/crypto/vfio_ap_ops.c:198:\tmutex_lock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-199-\tif (q-\u003ematrix_mdev \u0026\u0026 q-\u003ematrix_mdev-\u003ekvm)\ndrivers/s390/crypto/vfio_ap_ops.c-200-\t\tmutex_lock(\u0026q-\u003ematrix_mdev-\u003ekvm-\u003elock);\ndrivers/s390/crypto/vfio_ap_ops.c:201:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-202-}\n--\ndrivers/s390/crypto/vfio_ap_ops.c=552=static void vfio_ap_le_guid_to_be_uuid(guid_t *guid, unsigned long *uuid)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-581- *   Check vfio_ap_setirq() and vfio_ap_clrirq() for other possible RC.\ndrivers/s390/crypto/vfio_ap_ops.c:582: * We take the matrix_dev lock to ensure serialization on queues and\ndrivers/s390/crypto/vfio_ap_ops.c-583- * mediated device access.\n--\ndrivers/s390/crypto/vfio_ap_ops.c=588=static int handle_pqap(struct kvm_vcpu *vcpu)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-607-\ndrivers/s390/crypto/vfio_ap_ops.c:608:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-609-\n--\ndrivers/s390/crypto/vfio_ap_ops.c-647-\tvcpu-\u003erun-\u003es.regs.gprs[1] \u003e\u003e= 32;\ndrivers/s390/crypto/vfio_ap_ops.c:648:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-649-\treturn 0;\n--\ndrivers/s390/crypto/vfio_ap_ops.c=678=static bool vfio_ap_mdev_filter_cdoms(struct ap_matrix_mdev *matrix_mdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-683-\tbitmap_and(matrix_mdev-\u003eshadow_apcb.adm, matrix_mdev-\u003ematrix.adm,\ndrivers/s390/crypto/vfio_ap_ops.c:684:\t\t   (unsigned long *)matrix_dev-\u003einfo.adm, AP_DOMAINS);\ndrivers/s390/crypto/vfio_ap_ops.c-685-\n--\ndrivers/s390/crypto/vfio_ap_ops.c=727=static bool vfio_ap_mdev_filter_matrix(struct ap_matrix_mdev *matrix_mdev,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-735-\tbitmap_copy(prev_shadow_aqm, matrix_mdev-\u003eshadow_apcb.aqm, AP_DOMAINS);\ndrivers/s390/crypto/vfio_ap_ops.c:736:\tvfio_ap_matrix_init(\u0026matrix_dev-\u003einfo, \u0026matrix_mdev-\u003eshadow_apcb);\ndrivers/s390/crypto/vfio_ap_ops.c-737-\tbitmap_clear(apm_filtered, 0, AP_DEVICES);\n--\ndrivers/s390/crypto/vfio_ap_ops.c-744-\tbitmap_and(matrix_mdev-\u003eshadow_apcb.apm, matrix_mdev-\u003ematrix.apm,\ndrivers/s390/crypto/vfio_ap_ops.c:745:\t\t   (unsigned long *)matrix_dev-\u003einfo.apm, AP_DEVICES);\ndrivers/s390/crypto/vfio_ap_ops.c-746-\tbitmap_and(matrix_mdev-\u003eshadow_apcb.aqm, matrix_mdev-\u003ematrix.aqm,\ndrivers/s390/crypto/vfio_ap_ops.c:747:\t\t   (unsigned long *)matrix_dev-\u003einfo.aqm, AP_DOMAINS);\ndrivers/s390/crypto/vfio_ap_ops.c-748-\n--\ndrivers/s390/crypto/vfio_ap_ops.c=783=static int vfio_ap_mdev_init_dev(struct vfio_device *vdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-788-\tmatrix_mdev-\u003emdev = to_mdev_device(vdev-\u003edev);\ndrivers/s390/crypto/vfio_ap_ops.c:789:\tvfio_ap_matrix_init(\u0026matrix_dev-\u003einfo, \u0026matrix_mdev-\u003ematrix);\ndrivers/s390/crypto/vfio_ap_ops.c-790-\tmatrix_mdev-\u003epqap_hook = handle_pqap;\ndrivers/s390/crypto/vfio_ap_ops.c:791:\tvfio_ap_matrix_init(\u0026matrix_dev-\u003einfo, \u0026matrix_mdev-\u003eshadow_apcb);\ndrivers/s390/crypto/vfio_ap_ops.c-792-\thash_init(matrix_mdev-\u003eqtable.queues);\n--\ndrivers/s390/crypto/vfio_ap_ops.c=797=static int vfio_ap_mdev_probe(struct mdev_device *mdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-802-\tmatrix_mdev = vfio_alloc_device(ap_matrix_mdev, vdev, \u0026mdev-\u003edev,\ndrivers/s390/crypto/vfio_ap_ops.c:803:\t\t\t\t\t\u0026vfio_ap_matrix_dev_ops);\ndrivers/s390/crypto/vfio_ap_ops.c-804-\tif (IS_ERR(matrix_mdev))\n--\ndrivers/s390/crypto/vfio_ap_ops.c-812-\tdev_set_drvdata(\u0026mdev-\u003edev, matrix_mdev);\ndrivers/s390/crypto/vfio_ap_ops.c:813:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c:814:\tlist_add(\u0026matrix_mdev-\u003enode, \u0026matrix_dev-\u003emdev_list);\ndrivers/s390/crypto/vfio_ap_ops.c:815:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-816-\treturn 0;\n--\ndrivers/s390/crypto/vfio_ap_ops.c=867=static void vfio_ap_mdev_remove(struct mdev_device *mdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-872-\ndrivers/s390/crypto/vfio_ap_ops.c:873:\tmutex_lock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c:874:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-875-\tvfio_ap_mdev_reset_queues(matrix_mdev);\n--\ndrivers/s390/crypto/vfio_ap_ops.c-877-\tlist_del(\u0026matrix_mdev-\u003enode);\ndrivers/s390/crypto/vfio_ap_ops.c:878:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c:879:\tmutex_unlock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-880-\tvfio_put_device(\u0026matrix_mdev-\u003evdev);\n--\ndrivers/s390/crypto/vfio_ap_ops.c=929=static int vfio_ap_mdev_verify_no_sharing(struct ap_matrix_mdev *assignee,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-936-\ndrivers/s390/crypto/vfio_ap_ops.c:937:\tlist_for_each_entry(assigned_to, \u0026matrix_dev-\u003emdev_list, node) {\ndrivers/s390/crypto/vfio_ap_ops.c-938-\t\t/*\n--\ndrivers/s390/crypto/vfio_ap_ops.c=1568=static ssize_t control_domains_show(struct device *dev,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1576-\ndrivers/s390/crypto/vfio_ap_ops.c:1577:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-1578-\tfor_each_set_bit_inv(id, matrix_mdev-\u003ematrix.adm, max_domid + 1)\ndrivers/s390/crypto/vfio_ap_ops.c-1579-\t\tnchars += sysfs_emit_at(buf, nchars, \"%04lx\\n\", id);\ndrivers/s390/crypto/vfio_ap_ops.c:1580:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-1581-\n--\ndrivers/s390/crypto/vfio_ap_ops.c=1615=static ssize_t matrix_show(struct device *dev, struct device_attribute *attr,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1620-\ndrivers/s390/crypto/vfio_ap_ops.c:1621:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-1622-\tnchars = vfio_ap_mdev_matrix_show(\u0026matrix_mdev-\u003ematrix, buf);\ndrivers/s390/crypto/vfio_ap_ops.c:1623:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-1624-\n--\ndrivers/s390/crypto/vfio_ap_ops.c=1629=static ssize_t guest_matrix_show(struct device *dev,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1634-\ndrivers/s390/crypto/vfio_ap_ops.c:1635:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-1636-\tnchars = vfio_ap_mdev_matrix_show(\u0026matrix_mdev-\u003eshadow_apcb, buf);\ndrivers/s390/crypto/vfio_ap_ops.c:1637:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-1638-\n--\ndrivers/s390/crypto/vfio_ap_ops.c=1860=static void vfio_ap_mdev_dma_unmap(struct vfio_device *vdev, u64 iova,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1865-\ndrivers/s390/crypto/vfio_ap_ops.c:1866:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-1867-\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1869-\ndrivers/s390/crypto/vfio_ap_ops.c:1870:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-1871-}\n--\ndrivers/s390/crypto/vfio_ap_ops.c=1896=static struct vfio_ap_queue *vfio_ap_find_queue(int apqn)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1904-\ndrivers/s390/crypto/vfio_ap_ops.c:1905:\tif (queue-\u003eap_dev.device.driver == \u0026matrix_dev-\u003evfio_ap_drv-\u003edriver)\ndrivers/s390/crypto/vfio_ap_ops.c-1906-\t\tq = dev_get_drvdata(\u0026queue-\u003eap_dev.device);\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2259=static ssize_t vfio_ap_mdev_ioctl(struct vfio_device *vdev,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2265-\ndrivers/s390/crypto/vfio_ap_ops.c:2266:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2267-\tswitch (cmd) {\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2283-\t}\ndrivers/s390/crypto/vfio_ap_ops.c:2284:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2285-\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2289=static struct ap_matrix_mdev *vfio_ap_mdev_for_queue(struct vfio_ap_queue *q)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2294-\ndrivers/s390/crypto/vfio_ap_ops.c:2295:\tlist_for_each_entry(matrix_mdev, \u0026matrix_dev-\u003emdev_list, node) {\ndrivers/s390/crypto/vfio_ap_ops.c-2296-\t\tif (test_bit_inv(apid, matrix_mdev-\u003ematrix.apm) \u0026\u0026\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2304=static ssize_t status_show(struct device *dev,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2313-\ndrivers/s390/crypto/vfio_ap_ops.c:2314:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2315-\tq = dev_get_drvdata(\u0026apdev-\u003edevice);\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2339-\ndrivers/s390/crypto/vfio_ap_ops.c:2340:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2341-\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2352=static const struct attribute_group vfio_queue_attr_group = {\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2355-\ndrivers/s390/crypto/vfio_ap_ops.c:2356:static const struct vfio_device_ops vfio_ap_matrix_dev_ops = {\ndrivers/s390/crypto/vfio_ap_ops.c-2357-\t.init = vfio_ap_mdev_init_dev,\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2382=int vfio_ap_mdev_register(void)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2389-\ndrivers/s390/crypto/vfio_ap_ops.c:2390:\tmatrix_dev-\u003emdev_type.sysfs_name = VFIO_AP_MDEV_TYPE_HWVIRT;\ndrivers/s390/crypto/vfio_ap_ops.c:2391:\tmatrix_dev-\u003emdev_type.pretty_name = VFIO_AP_MDEV_NAME_HWVIRT;\ndrivers/s390/crypto/vfio_ap_ops.c:2392:\tmatrix_dev-\u003emdev_types = \u0026matrix_dev-\u003emdev_type;\ndrivers/s390/crypto/vfio_ap_ops.c:2393:\tret = mdev_register_parent(\u0026matrix_dev-\u003eparent, \u0026matrix_dev-\u003edevice,\ndrivers/s390/crypto/vfio_ap_ops.c-2394-\t\t\t\t   \u0026vfio_ap_matrix_driver,\ndrivers/s390/crypto/vfio_ap_ops.c:2395:\t\t\t\t   \u0026matrix_dev-\u003emdev_types, 1);\ndrivers/s390/crypto/vfio_ap_ops.c-2396-\tif (ret)\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2405=void vfio_ap_mdev_unregister(void)\ndrivers/s390/crypto/vfio_ap_ops.c-2406-{\ndrivers/s390/crypto/vfio_ap_ops.c:2407:\tmdev_unregister_parent(\u0026matrix_dev-\u003eparent);\ndrivers/s390/crypto/vfio_ap_ops.c-2408-\tmdev_unregister_driver(\u0026vfio_ap_matrix_driver);\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2465=void vfio_ap_mdev_remove_queue(struct ap_device *apdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2498-\t */\ndrivers/s390/crypto/vfio_ap_ops.c:2499:\tif (test_bit_inv(apid, (unsigned long *)matrix_dev-\u003einfo.apm) \u0026\u0026\ndrivers/s390/crypto/vfio_ap_ops.c:2500:\t    test_bit_inv(apqi, (unsigned long *)matrix_dev-\u003einfo.aqm)) {\ndrivers/s390/crypto/vfio_ap_ops.c-2501-\t\tvfio_ap_mdev_reset_queue(q);\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2528=int vfio_ap_mdev_resource_in_use(unsigned long *apm, unsigned long *aqm)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2531-\ndrivers/s390/crypto/vfio_ap_ops.c:2532:\tmutex_lock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c:2533:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2534-\tret = vfio_ap_mdev_verify_no_sharing(NULL, apm, aqm);\ndrivers/s390/crypto/vfio_ap_ops.c:2535:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c:2536:\tmutex_unlock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2537-\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2593=static void vfio_ap_mdev_cfg_remove(unsigned long *ap_remove,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2602-\ndrivers/s390/crypto/vfio_ap_ops.c:2603:\tlist_for_each_entry(matrix_mdev, \u0026matrix_dev-\u003emdev_list, node) {\ndrivers/s390/crypto/vfio_ap_ops.c-2604-\t\tmutex_lock(\u0026matrix_mdev-\u003ekvm-\u003elock);\ndrivers/s390/crypto/vfio_ap_ops.c:2605:\t\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2606-\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2620-\ndrivers/s390/crypto/vfio_ap_ops.c:2621:\t\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2622-\t\tmutex_unlock(\u0026matrix_mdev-\u003ekvm-\u003elock);\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2736=static void vfio_ap_mdev_cfg_add(unsigned long *apm_add, unsigned long *aqm_add,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2740-\ndrivers/s390/crypto/vfio_ap_ops.c:2741:\tif (list_empty(\u0026matrix_dev-\u003emdev_list))\ndrivers/s390/crypto/vfio_ap_ops.c-2742-\t\treturn;\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2745-\ndrivers/s390/crypto/vfio_ap_ops.c:2746:\tlist_for_each_entry(matrix_mdev, \u0026matrix_dev-\u003emdev_list, node) {\ndrivers/s390/crypto/vfio_ap_ops.c-2747-\t\tbitmap_and(matrix_mdev-\u003eapm_add,\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2799=void vfio_ap_on_cfg_changed(struct ap_config_info *cur_cfg_info,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2804-\ndrivers/s390/crypto/vfio_ap_ops.c:2805:\tmutex_lock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2806-\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2808-\tvfio_ap_mdev_on_cfg_add(cur_cfg_info, prev_cfg_info);\ndrivers/s390/crypto/vfio_ap_ops.c:2809:\tmemcpy(\u0026matrix_dev-\u003einfo, cur_cfg_info, sizeof(*cur_cfg_info));\ndrivers/s390/crypto/vfio_ap_ops.c-2810-\ndrivers/s390/crypto/vfio_ap_ops.c:2811:\tmutex_unlock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2812-}\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2814=static void vfio_ap_mdev_hot_plug_cfg(struct ap_matrix_mdev *matrix_mdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2819-\tmutex_lock(\u0026matrix_mdev-\u003ekvm-\u003elock);\ndrivers/s390/crypto/vfio_ap_ops.c:2820:\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2821-\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2839-\ndrivers/s390/crypto/vfio_ap_ops.c:2840:\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2841-\tmutex_unlock(\u0026matrix_mdev-\u003ekvm-\u003elock);\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2844=void vfio_ap_on_scan_complete(struct ap_config_info *new_config_info,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2848-\ndrivers/s390/crypto/vfio_ap_ops.c:2849:\tmutex_lock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2850-\ndrivers/s390/crypto/vfio_ap_ops.c:2851:\tlist_for_each_entry(matrix_mdev, \u0026matrix_dev-\u003emdev_list, node) {\ndrivers/s390/crypto/vfio_ap_ops.c-2852-\t\tif (bitmap_empty(matrix_mdev-\u003eapm_add, AP_DEVICES) \u0026\u0026\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2862-\ndrivers/s390/crypto/vfio_ap_ops.c:2863:\tmutex_unlock(\u0026matrix_dev-\u003eguests_lock);\ndrivers/s390/crypto/vfio_ap_ops.c-2864-}\n--\ndrivers/s390/crypto/vfio_ap_private.h-29-/**\ndrivers/s390/crypto/vfio_ap_private.h:30: * struct ap_matrix_dev - Contains the data for the matrix device.\ndrivers/s390/crypto/vfio_ap_private.h-31- *\n--\ndrivers/s390/crypto/vfio_ap_private.h-46- */\ndrivers/s390/crypto/vfio_ap_private.h:47:struct ap_matrix_dev {\ndrivers/s390/crypto/vfio_ap_private.h-48-\tstruct device device;\n--\ndrivers/s390/crypto/vfio_ap_private.h-58-\ndrivers/s390/crypto/vfio_ap_private.h:59:extern struct ap_matrix_dev *matrix_dev;\ndrivers/s390/crypto/vfio_ap_private.h-60-\n"
}

gemini-3.1-pro-preview

							input: 19328
							output: 18
							thoughts: 166

**My Initial Thoughts on VFIO-AP Device Creation**

Okay, so I'm tracing the VFIO-AP initialization. I see that `vfio_ap_matrix_dev_create` is called during module init within `vfio_ap_init`. That makes sense; it's registering a matrix device, the foundational element. Then, `vfio_ap_mdev_probe` gets called when a new mdev is created. I have to pause here. I wonder, can these mdevs, these software representations, even *be* created within a virtualized environment? Oh right, they're just software devices, created through sysfs, so logically, yes.

But hang on, there’s something important I need to consider. I'm focusing back on `vfio_ap_matrix_dev_create`. It looks like it calls `ap_qci(&matrix_dev->info)` under the condition that `test_facility(12)` evaluates to true. Facility 12 is AP Query Configuration Information. Now, the next question is if that facility is not available, will this whole process just fall apart? I need to check the code in `vfio_ap_matrix_dev_create` to ensure.

{
  "Expression": "ap_qci"
}

{
  "Output": "arch/s390/include/asm/ap.h=217=static inline struct ap_queue_status ap_zapq(ap_qid_t qid, int fbit)\n--\narch/s390/include/asm/ap.h-236- * struct ap_config_info - convenience struct for AP crypto\narch/s390/include/asm/ap.h:237: * config info as returned by the ap_qci() function.\narch/s390/include/asm/ap.h-238- */\narch/s390/include/asm/ap.h=239=struct ap_config_info {\n--\narch/s390/include/asm/ap.h-261-/**\narch/s390/include/asm/ap.h:262: * ap_qci(): Get AP configuration data\narch/s390/include/asm/ap.h-263- *\n--\narch/s390/include/asm/ap.h-265- */\narch/s390/include/asm/ap.h:266:static inline int ap_qci(struct ap_config_info *config)\narch/s390/include/asm/ap.h-267-{\n--\narch/s390/kvm/kvm-s390.c=3101=static int kvm_s390_apxa_installed(void)\n--\narch/s390/kvm/kvm-s390.c-3105-\tif (ap_instructions_available()) {\narch/s390/kvm/kvm-s390.c:3106:\t\tif (ap_qci(\u0026info) == 0)\narch/s390/kvm/kvm-s390.c-3107-\t\t\treturn info.apxa;\n--\ndrivers/s390/crypto/ap_bus.c=107=static struct ap_config_info qci[2];\ndrivers/s390/crypto/ap_bus.c:108:static struct ap_config_info *const ap_qci_info = \u0026qci[0];\ndrivers/s390/crypto/ap_bus.c:109:static struct ap_config_info *const ap_qci_info_old = \u0026qci[1];\ndrivers/s390/crypto/ap_bus.c-110-\n--\ndrivers/s390/crypto/ap_bus.c=209=static int ap_interrupts_available(void)\n--\ndrivers/s390/crypto/ap_bus.c-214-/**\ndrivers/s390/crypto/ap_bus.c:215: * ap_qci_available(): Test if AP configuration\ndrivers/s390/crypto/ap_bus.c-216- * information can be queried via QCI subfunction.\n--\ndrivers/s390/crypto/ap_bus.c-219- */\ndrivers/s390/crypto/ap_bus.c:220:static int ap_qci_available(void)\ndrivers/s390/crypto/ap_bus.c-221-{\n--\ndrivers/s390/crypto/ap_bus.c=241=static inline int ap_qact_available(void)\ndrivers/s390/crypto/ap_bus.c-242-{\ndrivers/s390/crypto/ap_bus.c:243:\treturn ap_qci_info-\u003eqact;\ndrivers/s390/crypto/ap_bus.c-244-}\n--\ndrivers/s390/crypto/ap_bus.c=251=int ap_sb_available(void)\ndrivers/s390/crypto/ap_bus.c-252-{\ndrivers/s390/crypto/ap_bus.c:253:\treturn ap_qci_info-\u003eapsb;\ndrivers/s390/crypto/ap_bus.c-254-}\n--\ndrivers/s390/crypto/ap_bus.c=270=static void __init ap_init_qci_info(void)\ndrivers/s390/crypto/ap_bus.c-271-{\ndrivers/s390/crypto/ap_bus.c:272:\tif (!ap_qci_available() ||\ndrivers/s390/crypto/ap_bus.c:273:\t    ap_qci(ap_qci_info)) {\ndrivers/s390/crypto/ap_bus.c-274-\t\tAP_DBF_INFO(\"%s QCI not supported\\n\", __func__);\n--\ndrivers/s390/crypto/ap_bus.c-276-\t}\ndrivers/s390/crypto/ap_bus.c:277:\tmemcpy(ap_qci_info_old, ap_qci_info, sizeof(*ap_qci_info));\ndrivers/s390/crypto/ap_bus.c-278-\tAP_DBF_INFO(\"%s successful fetched initial qci info\\n\", __func__);\ndrivers/s390/crypto/ap_bus.c-279-\ndrivers/s390/crypto/ap_bus.c:280:\tif (ap_qci_info-\u003eapxa) {\ndrivers/s390/crypto/ap_bus.c:281:\t\tif (ap_qci_info-\u003ena) {\ndrivers/s390/crypto/ap_bus.c:282:\t\t\tap_max_adapter_id = ap_qci_info-\u003ena;\ndrivers/s390/crypto/ap_bus.c-283-\t\t\tAP_DBF_INFO(\"%s new ap_max_adapter_id is %d\\n\",\n--\ndrivers/s390/crypto/ap_bus.c-285-\t\t}\ndrivers/s390/crypto/ap_bus.c:286:\t\tif (ap_qci_info-\u003end) {\ndrivers/s390/crypto/ap_bus.c:287:\t\t\tap_max_domain_id = ap_qci_info-\u003end;\ndrivers/s390/crypto/ap_bus.c-288-\t\t\tAP_DBF_INFO(\"%s new ap_max_domain_id is %d\\n\",\n--\ndrivers/s390/crypto/ap_bus.c=310=static inline int ap_test_config_card_id(unsigned int id)\n--\ndrivers/s390/crypto/ap_bus.c-313-\t\treturn 0;\ndrivers/s390/crypto/ap_bus.c:314:\tif (ap_qci_info-\u003eflags)\ndrivers/s390/crypto/ap_bus.c:315:\t\treturn ap_test_config(ap_qci_info-\u003eapm, id);\ndrivers/s390/crypto/ap_bus.c-316-\treturn 1;\n--\ndrivers/s390/crypto/ap_bus.c=327=int ap_test_config_usage_domain(unsigned int domain)\n--\ndrivers/s390/crypto/ap_bus.c-330-\t\treturn 0;\ndrivers/s390/crypto/ap_bus.c:331:\tif (ap_qci_info-\u003eflags)\ndrivers/s390/crypto/ap_bus.c:332:\t\treturn ap_test_config(ap_qci_info-\u003eaqm, domain);\ndrivers/s390/crypto/ap_bus.c-333-\treturn 1;\n--\ndrivers/s390/crypto/ap_bus.c=345=int ap_test_config_ctrl_domain(unsigned int domain)\ndrivers/s390/crypto/ap_bus.c-346-{\ndrivers/s390/crypto/ap_bus.c:347:\tif (!ap_qci_info || domain \u003e ap_max_domain_id)\ndrivers/s390/crypto/ap_bus.c-348-\t\treturn 0;\ndrivers/s390/crypto/ap_bus.c:349:\treturn ap_test_config(ap_qci_info-\u003eadm, domain);\ndrivers/s390/crypto/ap_bus.c-350-}\n--\ndrivers/s390/crypto/ap_bus.c=1349=static ssize_t ap_control_domain_mask_show(const struct bus_type *bus, char *buf)\ndrivers/s390/crypto/ap_bus.c-1350-{\ndrivers/s390/crypto/ap_bus.c:1351:\tif (!ap_qci_info-\u003eflags)\t/* QCI not supported */\ndrivers/s390/crypto/ap_bus.c-1352-\t\treturn sysfs_emit(buf, \"not supported\\n\");\n--\ndrivers/s390/crypto/ap_bus.c-1354-\treturn sysfs_emit(buf, \"0x%08x%08x%08x%08x%08x%08x%08x%08x\\n\",\ndrivers/s390/crypto/ap_bus.c:1355:\t\t\t  ap_qci_info-\u003eadm[0], ap_qci_info-\u003eadm[1],\ndrivers/s390/crypto/ap_bus.c:1356:\t\t\t  ap_qci_info-\u003eadm[2], ap_qci_info-\u003eadm[3],\ndrivers/s390/crypto/ap_bus.c:1357:\t\t\t  ap_qci_info-\u003eadm[4], ap_qci_info-\u003eadm[5],\ndrivers/s390/crypto/ap_bus.c:1358:\t\t\t  ap_qci_info-\u003eadm[6], ap_qci_info-\u003eadm[7]);\ndrivers/s390/crypto/ap_bus.c-1359-}\n--\ndrivers/s390/crypto/ap_bus.c=1363=static ssize_t ap_usage_domain_mask_show(const struct bus_type *bus, char *buf)\ndrivers/s390/crypto/ap_bus.c-1364-{\ndrivers/s390/crypto/ap_bus.c:1365:\tif (!ap_qci_info-\u003eflags)\t/* QCI not supported */\ndrivers/s390/crypto/ap_bus.c-1366-\t\treturn sysfs_emit(buf, \"not supported\\n\");\n--\ndrivers/s390/crypto/ap_bus.c-1368-\treturn sysfs_emit(buf, \"0x%08x%08x%08x%08x%08x%08x%08x%08x\\n\",\ndrivers/s390/crypto/ap_bus.c:1369:\t\t\t  ap_qci_info-\u003eaqm[0], ap_qci_info-\u003eaqm[1],\ndrivers/s390/crypto/ap_bus.c:1370:\t\t\t  ap_qci_info-\u003eaqm[2], ap_qci_info-\u003eaqm[3],\ndrivers/s390/crypto/ap_bus.c:1371:\t\t\t  ap_qci_info-\u003eaqm[4], ap_qci_info-\u003eaqm[5],\ndrivers/s390/crypto/ap_bus.c:1372:\t\t\t  ap_qci_info-\u003eaqm[6], ap_qci_info-\u003eaqm[7]);\ndrivers/s390/crypto/ap_bus.c-1373-}\n--\ndrivers/s390/crypto/ap_bus.c=1377=static ssize_t ap_adapter_mask_show(const struct bus_type *bus, char *buf)\ndrivers/s390/crypto/ap_bus.c-1378-{\ndrivers/s390/crypto/ap_bus.c:1379:\tif (!ap_qci_info-\u003eflags)\t/* QCI not supported */\ndrivers/s390/crypto/ap_bus.c-1380-\t\treturn sysfs_emit(buf, \"not supported\\n\");\n--\ndrivers/s390/crypto/ap_bus.c-1382-\treturn sysfs_emit(buf, \"0x%08x%08x%08x%08x%08x%08x%08x%08x\\n\",\ndrivers/s390/crypto/ap_bus.c:1383:\t\t\t  ap_qci_info-\u003eapm[0], ap_qci_info-\u003eapm[1],\ndrivers/s390/crypto/ap_bus.c:1384:\t\t\t  ap_qci_info-\u003eapm[2], ap_qci_info-\u003eapm[3],\ndrivers/s390/crypto/ap_bus.c:1385:\t\t\t  ap_qci_info-\u003eapm[4], ap_qci_info-\u003eapm[5],\ndrivers/s390/crypto/ap_bus.c:1386:\t\t\t  ap_qci_info-\u003eapm[6], ap_qci_info-\u003eapm[7]);\ndrivers/s390/crypto/ap_bus.c-1387-}\n--\ndrivers/s390/crypto/ap_bus.c=1747=static ssize_t features_show(const struct bus_type *bus, char *buf)\n--\ndrivers/s390/crypto/ap_bus.c-1750-\ndrivers/s390/crypto/ap_bus.c:1751:\tif (!ap_qci_info-\u003eflags)\t/* QCI not supported */\ndrivers/s390/crypto/ap_bus.c-1752-\t\treturn sysfs_emit(buf, \"-\\n\");\ndrivers/s390/crypto/ap_bus.c-1753-\ndrivers/s390/crypto/ap_bus.c:1754:\tif (ap_qci_info-\u003eapsc)\ndrivers/s390/crypto/ap_bus.c-1755-\t\tn += sysfs_emit_at(buf, n, \"APSC \");\ndrivers/s390/crypto/ap_bus.c:1756:\tif (ap_qci_info-\u003eapxa)\ndrivers/s390/crypto/ap_bus.c-1757-\t\tn += sysfs_emit_at(buf, n, \"APXA \");\ndrivers/s390/crypto/ap_bus.c:1758:\tif (ap_qci_info-\u003eqact)\ndrivers/s390/crypto/ap_bus.c-1759-\t\tn += sysfs_emit_at(buf, n, \"QACT \");\ndrivers/s390/crypto/ap_bus.c:1760:\tif (ap_qci_info-\u003erc8a)\ndrivers/s390/crypto/ap_bus.c-1761-\t\tn += sysfs_emit_at(buf, n, \"RC8A \");\ndrivers/s390/crypto/ap_bus.c:1762:\tif (ap_qci_info-\u003eapsb)\ndrivers/s390/crypto/ap_bus.c-1763-\t\tn += sysfs_emit_at(buf, n, \"APSB \");\n--\ndrivers/s390/crypto/ap_bus.c=1923=static int __drv_notify_config_changed(struct device_driver *drv, void *data)\n--\ndrivers/s390/crypto/ap_bus.c-1928-\t\tif (ap_drv-\u003eon_config_changed)\ndrivers/s390/crypto/ap_bus.c:1929:\t\t\tap_drv-\u003eon_config_changed(ap_qci_info, ap_qci_info_old);\ndrivers/s390/crypto/ap_bus.c-1930-\t\tmodule_put(drv-\u003eowner);\n--\ndrivers/s390/crypto/ap_bus.c=1944=static int __drv_notify_scan_complete(struct device_driver *drv, void *data)\n--\ndrivers/s390/crypto/ap_bus.c-1949-\t\tif (ap_drv-\u003eon_scan_complete)\ndrivers/s390/crypto/ap_bus.c:1950:\t\t\tap_drv-\u003eon_scan_complete(ap_qci_info,\ndrivers/s390/crypto/ap_bus.c:1951:\t\t\t\t\t\t ap_qci_info_old);\ndrivers/s390/crypto/ap_bus.c-1952-\t\tmodule_put(drv-\u003eowner);\n--\ndrivers/s390/crypto/ap_bus.c=2311=static bool ap_get_configuration(void)\ndrivers/s390/crypto/ap_bus.c-2312-{\ndrivers/s390/crypto/ap_bus.c:2313:\tif (!ap_qci_info-\u003eflags)\t/* QCI not supported */\ndrivers/s390/crypto/ap_bus.c-2314-\t\treturn false;\ndrivers/s390/crypto/ap_bus.c-2315-\ndrivers/s390/crypto/ap_bus.c:2316:\tmemcpy(ap_qci_info_old, ap_qci_info, sizeof(*ap_qci_info));\ndrivers/s390/crypto/ap_bus.c:2317:\tap_qci(ap_qci_info);\ndrivers/s390/crypto/ap_bus.c-2318-\ndrivers/s390/crypto/ap_bus.c:2319:\treturn memcmp(ap_qci_info, ap_qci_info_old,\ndrivers/s390/crypto/ap_bus.c-2320-\t\t      sizeof(struct ap_config_info)) != 0;\n--\ndrivers/s390/crypto/ap_bus.c=2329=static bool ap_config_has_new_aps(void)\n--\ndrivers/s390/crypto/ap_bus.c-2333-\ndrivers/s390/crypto/ap_bus.c:2334:\tif (!ap_qci_info-\u003eflags)\ndrivers/s390/crypto/ap_bus.c-2335-\t\treturn false;\ndrivers/s390/crypto/ap_bus.c-2336-\ndrivers/s390/crypto/ap_bus.c:2337:\tbitmap_andnot(m, (unsigned long *)ap_qci_info-\u003eapm,\ndrivers/s390/crypto/ap_bus.c:2338:\t\t      (unsigned long *)ap_qci_info_old-\u003eapm, AP_DEVICES);\ndrivers/s390/crypto/ap_bus.c-2339-\tif (!bitmap_empty(m, AP_DEVICES))\n--\ndrivers/s390/crypto/ap_bus.c=2351=static bool ap_config_has_new_doms(void)\n--\ndrivers/s390/crypto/ap_bus.c-2354-\ndrivers/s390/crypto/ap_bus.c:2355:\tif (!ap_qci_info-\u003eflags)\ndrivers/s390/crypto/ap_bus.c-2356-\t\treturn false;\ndrivers/s390/crypto/ap_bus.c-2357-\ndrivers/s390/crypto/ap_bus.c:2358:\tbitmap_andnot(m, (unsigned long *)ap_qci_info-\u003eaqm,\ndrivers/s390/crypto/ap_bus.c:2359:\t\t      (unsigned long *)ap_qci_info_old-\u003eaqm, AP_DOMAINS);\ndrivers/s390/crypto/ap_bus.c-2360-\tif (!bitmap_empty(m, AP_DOMAINS))\n--\ndrivers/s390/crypto/vfio_ap_drv.c=86=static int vfio_ap_matrix_dev_create(void)\n--\ndrivers/s390/crypto/vfio_ap_drv.c-106-\tif (test_facility(12)) {\ndrivers/s390/crypto/vfio_ap_drv.c:107:\t\tret = ap_qci(\u0026matrix_dev-\u003einfo);\ndrivers/s390/crypto/vfio_ap_drv.c-108-\t\tif (ret)\n"
}

gemini-3.1-pro-preview

							input: 24998
							output: 18
							thoughts: 299

**My Analysis of VFIO AP Device Creation**

Okay, so I'm looking at this `vfio_ap_matrix_dev_create` function, specifically that `test_facility(12)` check. My initial thought was that if facility 12 wasn't present, the whole thing would error out. But hang on, it doesn't! It just *skips* the `ap_qci` call. And since the `matrix_dev->info` struct was `kzalloc_obj`'d, it'll just be zeroed out. That means the device creation *succeeds* even without the facility. So, the matrix device gets registered, even in this "partial" state. Interesting.

Now, can we actually create an mdev on top of this? I need to check the `vfio_ap_mdev_probe` and `vfio_ap_mdev_init_dev` functions to see what happens there. My immediate thought is, QEMU might not be fully emulating the AP instructions by default, but KVM can pass them through. That's the difference.

And wait, isn't syzkaller often run with KVM on s390x? Yes, it is! So it *should* have the capability to interact with these devices, at least in a passthrough configuration. Which brings me to the core question: does syzkaller have existing descriptions or fuzzing coverage for `vfio_ap`? I need to check the syzkaller code base to see if there are any definitions or test cases related to the VFIO AP subsystem. That's the key to exploiting any vulnerabilities here. I'm going to find out.

{
  "Expression": "vfio_ap"
}

{
  "Output": "\nFull output is too long, showing 500 out of 1503 lines.\nUse more precise expression if possible.\n\nDocumentation/arch/s390/vfio-ap-locking.rst=6=This document describes the locks that are pertinent to the secure operation\nDocumentation/arch/s390/vfio-ap-locking.rst:7:of the vfio_ap device driver. Throughout this document, the following variables\nDocumentation/arch/s390/vfio-ap-locking.rst-8-will be used to denote instances of the structures herein described:\n--\nDocumentation/arch/s390/vfio-ap-locking.rst-15-\nDocumentation/arch/s390/vfio-ap-locking.rst:16:The Matrix Devices Lock (drivers/s390/crypto/vfio_ap_private.h)\nDocumentation/arch/s390/vfio-ap-locking.rst-17----------------------------------------------------------------\n--\nDocumentation/arch/s390/vfio-ap-locking.rst=32=or using the data from a field contained within a matrix_mdev instance\nDocumentation/arch/s390/vfio-ap-locking.rst:33:representing one of the vfio_ap device driver's mediated devices.\nDocumentation/arch/s390/vfio-ap-locking.rst-34-\n--\nDocumentation/arch/s390/vfio-ap-locking.rst=46=The KVM Lock (kvm-\u003elock) controls access to the state data for a KVM guest. This\nDocumentation/arch/s390/vfio-ap-locking.rst:47:lock must be held by the vfio_ap device driver while one or more AP adapters,\nDocumentation/arch/s390/vfio-ap-locking.rst-48-domains or control domains are being plugged into or unplugged from the guest.\n--\nDocumentation/arch/s390/vfio-ap-locking.rst=52=been attached to the KVM guest.\nDocumentation/arch/s390/vfio-ap-locking.rst-53-\nDocumentation/arch/s390/vfio-ap-locking.rst:54:The Guests Lock (drivers/s390/crypto/vfio_ap_private.h)\nDocumentation/arch/s390/vfio-ap-locking.rst-55------------------------------------------------------------\n--\nDocumentation/arch/s390/vfio-ap-locking.rst=69=KVM guest. This lock must be held:\nDocumentation/arch/s390/vfio-ap-locking.rst-70-\nDocumentation/arch/s390/vfio-ap-locking.rst:71:1. To control access to the KVM pointer (matrix_mdev-\u003ekvm) while the vfio_ap\nDocumentation/arch/s390/vfio-ap-locking.rst-72-   device driver is using it to plug/unplug AP devices passed through to the KVM\n--\nDocumentation/arch/s390/vfio-ap-locking.rst-79-\nDocumentation/arch/s390/vfio-ap-locking.rst:80:   For example, when a queue device is removed from the vfio_ap device driver,\nDocumentation/arch/s390/vfio-ap-locking.rst-81-   if the adapter is passed through to a KVM guest, it will have to be\n--\nDocumentation/arch/s390/vfio-ap.rst=188=The design introduces three new objects:\n--\nDocumentation/arch/s390/vfio-ap.rst-190-1. AP matrix device\nDocumentation/arch/s390/vfio-ap.rst:191:2. VFIO AP device driver (vfio_ap.ko)\nDocumentation/arch/s390/vfio-ap.rst-192-3. VFIO AP mediated pass-through device\n--\nDocumentation/arch/s390/vfio-ap.rst=194=The VFIO AP device driver\nDocumentation/arch/s390/vfio-ap.rst-195--------------------------\nDocumentation/arch/s390/vfio-ap.rst:196:The VFIO AP (vfio_ap) device driver serves the following purposes:\nDocumentation/arch/s390/vfio-ap.rst-197-\n--\nDocumentation/arch/s390/vfio-ap.rst-199-\nDocumentation/arch/s390/vfio-ap.rst:200:2. Sets up the VFIO mediated device interfaces to manage a vfio_ap mediated\nDocumentation/arch/s390/vfio-ap.rst-201-   device and creates the sysfs interfaces for assigning adapters, usage\n--\nDocumentation/arch/s390/vfio-ap.rst=211=reserved::\n--\nDocumentation/arch/s390/vfio-ap.rst-231-  |                  |                      |                  |\nDocumentation/arch/s390/vfio-ap.rst:232:  |      ap_bus      +--------------------- \u003e  vfio_ap driver  |\nDocumentation/arch/s390/vfio-ap.rst-233-  |                  |       8 probe        |                  |\n--\nDocumentation/arch/s390/vfio-ap.rst-243-\t | |                              |                            |\nDocumentation/arch/s390/vfio-ap.rst:244:\t | | 9 create vfio_ap-passthrough |                            |\nDocumentation/arch/s390/vfio-ap.rst-245-\t | +------------------------------+                            |\n--\nDocumentation/arch/s390/vfio-ap.rst=249=The process for reserving an AP queue for use by a KVM guest is:\nDocumentation/arch/s390/vfio-ap.rst-250-\nDocumentation/arch/s390/vfio-ap.rst:251:1. The administrator loads the vfio_ap device driver\nDocumentation/arch/s390/vfio-ap.rst-252-2. The vfio-ap driver during its initialization will register a single 'matrix'\nDocumentation/arch/s390/vfio-ap.rst-253-   device with the device core. This will serve as the parent device for\nDocumentation/arch/s390/vfio-ap.rst:254:   all vfio_ap mediated devices used to configure an AP matrix for a guest.\nDocumentation/arch/s390/vfio-ap.rst:255:3. The /sys/devices/vfio_ap/matrix device is created by the device core\nDocumentation/arch/s390/vfio-ap.rst:256:4. The vfio_ap device driver will register with the AP bus for AP queue devices\nDocumentation/arch/s390/vfio-ap.rst:257:   of type 10 and higher (CEX4 and newer). The driver will provide the vfio_ap\nDocumentation/arch/s390/vfio-ap.rst-258-   driver's probe and remove callback interfaces. Devices older than CEX4 queues\n--\nDocumentation/arch/s390/vfio-ap.rst-262-   systems around on which to test.\nDocumentation/arch/s390/vfio-ap.rst:263:5. The AP bus registers the vfio_ap device driver with the device core\nDocumentation/arch/s390/vfio-ap.rst-264-6. The administrator edits the AP adapter and queue masks to reserve AP queues\nDocumentation/arch/s390/vfio-ap.rst:265:   for use by the vfio_ap device driver.\nDocumentation/arch/s390/vfio-ap.rst:266:7. The AP bus removes the AP queues reserved for the vfio_ap driver from the\nDocumentation/arch/s390/vfio-ap.rst-267-   default zcrypt cex4queue driver.\nDocumentation/arch/s390/vfio-ap.rst:268:8. The AP bus probes the vfio_ap device driver to bind the queues reserved for\nDocumentation/arch/s390/vfio-ap.rst-269-   it.\nDocumentation/arch/s390/vfio-ap.rst:270:9. The administrator creates a passthrough type vfio_ap mediated device to be\nDocumentation/arch/s390/vfio-ap.rst-271-   used by a guest\n--\nDocumentation/arch/s390/vfio-ap.rst=278=device core driver to:\nDocumentation/arch/s390/vfio-ap.rst-279-\nDocumentation/arch/s390/vfio-ap.rst:280:* Register an AP mediated bus driver to add a vfio_ap mediated device to and\nDocumentation/arch/s390/vfio-ap.rst-281-  remove it from a VFIO group.\nDocumentation/arch/s390/vfio-ap.rst:282:* Create and destroy a vfio_ap mediated device\nDocumentation/arch/s390/vfio-ap.rst:283:* Add a vfio_ap mediated device to and remove it from the AP mediated bus driver\nDocumentation/arch/s390/vfio-ap.rst:284:* Add a vfio_ap mediated device to and remove it from an IOMMU group\nDocumentation/arch/s390/vfio-ap.rst-285-\n--\nDocumentation/arch/s390/vfio-ap.rst=287=of the VFIO AP mediated device driver::\n--\nDocumentation/arch/s390/vfio-ap.rst-301-   | |Physical | +\u003c-----------------------+              |\nDocumentation/arch/s390/vfio-ap.rst:302:   | | device  | |                        |  vfio_ap.ko  |\u003c-\u003e matrix\nDocumentation/arch/s390/vfio-ap.rst-303-   | |interface| +-----------------------\u003e+              |    device\n--\nDocumentation/arch/s390/vfio-ap.rst-306-\nDocumentation/arch/s390/vfio-ap.rst:307:During initialization of the vfio_ap module, the matrix device is registered\nDocumentation/arch/s390/vfio-ap.rst-308-with an 'mdev_parent_ops' structure that provides the sysfs attribute\n--\nDocumentation/arch/s390/vfio-ap.rst=310=matrix device.\n--\nDocumentation/arch/s390/vfio-ap.rst-326-\nDocumentation/arch/s390/vfio-ap.rst:327:      /sys/devices/vfio_ap/matrix/mdev_supported_types/vfio_ap-passthrough\nDocumentation/arch/s390/vfio-ap.rst-328-\n--\nDocumentation/arch/s390/vfio-ap.rst-343-\t* available_instances:\nDocumentation/arch/s390/vfio-ap.rst:344:\t    the number of vfio_ap mediated passthrough devices\nDocumentation/arch/s390/vfio-ap.rst-345-\t    that can be created\n--\nDocumentation/arch/s390/vfio-ap.rst-351-    framework, the sysfs attribute files identified in the 'mdev_attr_groups'\nDocumentation/arch/s390/vfio-ap.rst:352:    structure will be created in the vfio_ap mediated device's directory. The\nDocumentation/arch/s390/vfio-ap.rst:353:    sysfs attributes for a vfio_ap mediated device are:\nDocumentation/arch/s390/vfio-ap.rst-354-\n--\nDocumentation/arch/s390/vfio-ap.rst-356-      Write-only attributes for assigning/unassigning an AP adapter to/from the\nDocumentation/arch/s390/vfio-ap.rst:357:      vfio_ap mediated device. To assign/unassign an adapter, the APID of the\nDocumentation/arch/s390/vfio-ap.rst-358-      adapter is echoed into the respective attribute file.\n--\nDocumentation/arch/s390/vfio-ap.rst-360-      Write-only attributes for assigning/unassigning an AP usage domain to/from\nDocumentation/arch/s390/vfio-ap.rst:361:      the vfio_ap mediated device. To assign/unassign a domain, the domain\nDocumentation/arch/s390/vfio-ap.rst-362-      number of the usage domain is echoed into the respective attribute\n--\nDocumentation/arch/s390/vfio-ap.rst-365-      A read-only file for displaying the APQNs derived from the Cartesian\nDocumentation/arch/s390/vfio-ap.rst:366:      product of the adapter and domain numbers assigned to the vfio_ap mediated\nDocumentation/arch/s390/vfio-ap.rst-367-      device.\n--\nDocumentation/arch/s390/vfio-ap.rst-371-      fields respectively of the KVM guest's CRYCB. This may differ from the\nDocumentation/arch/s390/vfio-ap.rst:372:      the APQNs assigned to the vfio_ap mediated device if any APQN does not\nDocumentation/arch/s390/vfio-ap.rst:373:      reference a queue device bound to the vfio_ap device driver (i.e., the\nDocumentation/arch/s390/vfio-ap.rst-374-      queue is not in the host's AP configuration).\n--\nDocumentation/arch/s390/vfio-ap.rst-376-      Write-only attributes for assigning/unassigning an AP control domain\nDocumentation/arch/s390/vfio-ap.rst:377:      to/from the vfio_ap mediated device. To assign/unassign a control domain,\nDocumentation/arch/s390/vfio-ap.rst-378-      the ID of the domain to be assigned/unassigned is echoed into the\n--\nDocumentation/arch/s390/vfio-ap.rst-381-      A read-only file for displaying the control domain numbers assigned to the\nDocumentation/arch/s390/vfio-ap.rst:382:      vfio_ap mediated device.\nDocumentation/arch/s390/vfio-ap.rst-383-    ap_config:\nDocumentation/arch/s390/vfio-ap.rst-384-      A read/write file that, when written to, allows all three of the\nDocumentation/arch/s390/vfio-ap.rst:385:      vfio_ap mediated device's ap matrix masks to be replaced in one shot.\nDocumentation/arch/s390/vfio-ap.rst-386-      Three masks are given, one for adapters, one for domains, and one for\n--\nDocumentation/arch/s390/vfio-ap.rst-416-  create:\nDocumentation/arch/s390/vfio-ap.rst:417:    allocates the ap_matrix_mdev structure used by the vfio_ap driver to:\nDocumentation/arch/s390/vfio-ap.rst-418-\n--\nDocumentation/arch/s390/vfio-ap.rst-424-      referencing queue devices that do not exist, or are not bound to the\nDocumentation/arch/s390/vfio-ap.rst:425:      vfio_ap device driver.\nDocumentation/arch/s390/vfio-ap.rst-426-\nDocumentation/arch/s390/vfio-ap.rst-427-  remove:\nDocumentation/arch/s390/vfio-ap.rst:428:    deallocates the vfio_ap mediated device's ap_matrix_mdev structure.\nDocumentation/arch/s390/vfio-ap.rst-429-    This will be allowed only if a running guest is not using the mdev.\n--\nDocumentation/arch/s390/vfio-ap.rst-437-    and configures the guest's access to the AP matrix defined via the\nDocumentation/arch/s390/vfio-ap.rst:438:    vfio_ap mediated device's sysfs attribute files.\nDocumentation/arch/s390/vfio-ap.rst-439-\n--\nDocumentation/arch/s390/vfio-ap.rst=451=configured via its APCB by:\n--\nDocumentation/arch/s390/vfio-ap.rst-453-* Setting the bits in the APM corresponding to the APIDs assigned to the\nDocumentation/arch/s390/vfio-ap.rst:454:  vfio_ap mediated device via its 'assign_adapter' interface.\nDocumentation/arch/s390/vfio-ap.rst-455-* Setting the bits in the AQM corresponding to the domains assigned to the\nDocumentation/arch/s390/vfio-ap.rst:456:  vfio_ap mediated device via its 'assign_domain' interface.\nDocumentation/arch/s390/vfio-ap.rst-457-* Setting the bits in the ADM corresponding to the domain dIDs assigned to the\nDocumentation/arch/s390/vfio-ap.rst:458:  vfio_ap mediated device via its 'assign_control_domains' interface.\nDocumentation/arch/s390/vfio-ap.rst-459-\n--\nDocumentation/arch/s390/vfio-ap.rst=461=is not bound to the device driver facilitating its pass-through. Consequently,\nDocumentation/arch/s390/vfio-ap.rst:462:an APQN that does not reference a queue device bound to the vfio_ap device\nDocumentation/arch/s390/vfio-ap.rst-463-driver will not be assigned to a KVM guest's matrix. The AP architecture,\nDocumentation/arch/s390/vfio-ap.rst=464=however, does not provide a means to filter individual APQNs from the guest's\nDocumentation/arch/s390/vfio-ap.rst:465:matrix, so the adapters, domains and control domains assigned to vfio_ap\nDocumentation/arch/s390/vfio-ap.rst-466-mediated device via its sysfs 'assign_adapter', 'assign_domain' and\n--\nDocumentation/arch/s390/vfio-ap.rst=468=configuration to a guest:\n--\nDocumentation/arch/s390/vfio-ap.rst-474-* Each APQN derived from the Cartesian product of the APIDs and APQIs assigned\nDocumentation/arch/s390/vfio-ap.rst:475:  to the vfio_ap mdev is examined and if any one of them does not reference a\nDocumentation/arch/s390/vfio-ap.rst:476:  queue device bound to the vfio_ap device driver, the adapter will not be\nDocumentation/arch/s390/vfio-ap.rst-477-  plugged into the guest (i.e., the bit corresponding to its APID will not be\n--\nDocumentation/arch/s390/vfio-ap.rst=563=These are the steps:\nDocumentation/arch/s390/vfio-ap.rst-564-\nDocumentation/arch/s390/vfio-ap.rst:565:1. Install the vfio_ap module on the linux host. The dependency chain for the\nDocumentation/arch/s390/vfio-ap.rst:566:   vfio_ap module is:\nDocumentation/arch/s390/vfio-ap.rst-567-   * iommu\n--\nDocumentation/arch/s390/vfio-ap.rst-574-\nDocumentation/arch/s390/vfio-ap.rst:575:   To build the vfio_ap module, the kernel build must be configured with the\nDocumentation/arch/s390/vfio-ap.rst-576-   following Kconfig elements selected:\n--\nDocumentation/arch/s390/vfio-ap.rst-582-\nDocumentation/arch/s390/vfio-ap.rst:583:   If using make menuconfig select the following to build the vfio_ap module::\nDocumentation/arch/s390/vfio-ap.rst-584-\n--\nDocumentation/arch/s390/vfio-ap.rst-597-   queue device drivers. All remaining APQNs are available for use by\nDocumentation/arch/s390/vfio-ap.rst:598:   any other device driver. The vfio_ap device driver is currently the only\nDocumentation/arch/s390/vfio-ap.rst-599-   non-default device driver. The location of the sysfs files containing the\n--\nDocumentation/arch/s390/vfio-ap.rst-618-   All other APQNs are available to the non-default device drivers such as the\nDocumentation/arch/s390/vfio-ap.rst:619:   vfio_ap driver.\nDocumentation/arch/s390/vfio-ap.rst-620-\n--\nDocumentation/arch/s390/vfio-ap.rst-646-   match is detected,  only the default AP queue device drivers will be probed;\nDocumentation/arch/s390/vfio-ap.rst:647:   otherwise, the vfio_ap device driver will be probed.\nDocumentation/arch/s390/vfio-ap.rst-648-\n--\nDocumentation/arch/s390/vfio-ap.rst-708-   **Note:**\nDocumentation/arch/s390/vfio-ap.rst:709:   Changing a mask such that one or more APQNs will be taken from a vfio_ap\nDocumentation/arch/s390/vfio-ap.rst-710-   mediated device (see below) will fail with an error (EBUSY). A message\n--\nDocumentation/arch/s390/vfio-ap.rst-712-   command. The output identifies each APQN flagged as 'in use' and identifies\nDocumentation/arch/s390/vfio-ap.rst:713:   the vfio_ap mediated device to which it is assigned; for example:\nDocumentation/arch/s390/vfio-ap.rst-714-\n--\nDocumentation/arch/s390/vfio-ap.rst=718=Securing the APQNs for our example\n--\nDocumentation/arch/s390/vfio-ap.rst-720-   To secure the AP queues 05.0004, 05.0047, 05.00ab, 05.00ff, 06.0004, 06.0047,\nDocumentation/arch/s390/vfio-ap.rst:721:   06.00ab, and 06.00ff for use by the vfio_ap device driver, the corresponding\nDocumentation/arch/s390/vfio-ap.rst-722-   APQNs can be removed from the default masks using either of the following\n--\nDocumentation/arch/s390/vfio-ap.rst-737-   This will result in AP queues 05.0004, 05.0047, 05.00ab, 05.00ff, 06.0004,\nDocumentation/arch/s390/vfio-ap.rst:738:   06.0047, 06.00ab, and 06.00ff getting bound to the vfio_ap device driver. The\nDocumentation/arch/s390/vfio-ap.rst:739:   sysfs directory for the vfio_ap device driver will now contain symbolic links\nDocumentation/arch/s390/vfio-ap.rst-740-   to the AP queue devices bound to it::\n--\nDocumentation/arch/s390/vfio-ap.rst-743-     ... [drivers]\nDocumentation/arch/s390/vfio-ap.rst:744:     ...... [vfio_ap]\nDocumentation/arch/s390/vfio-ap.rst-745-     ......... [05.0004]\n--\nDocumentation/arch/s390/vfio-ap.rst-754-   Keep in mind that only type 10 and newer adapters (i.e., CEX4 and later)\nDocumentation/arch/s390/vfio-ap.rst:755:   can be bound to the vfio_ap device driver. The reason for this is to\nDocumentation/arch/s390/vfio-ap.rst-756-   simplify the implementation by not needlessly complicating the design by\n--\nDocumentation/arch/s390/vfio-ap.rst-760-   The administrator, therefore, must take care to secure only AP queues that\nDocumentation/arch/s390/vfio-ap.rst:761:   can be bound to the vfio_ap device driver. The device type for a given AP\nDocumentation/arch/s390/vfio-ap.rst-762-   queue device can be read from the parent card's sysfs directory. For example,\n--\nDocumentation/arch/s390/vfio-ap.rst-767-   The hwtype must be 10 or higher (CEX4 or newer) in order to be bound to the\nDocumentation/arch/s390/vfio-ap.rst:768:   vfio_ap device driver.\nDocumentation/arch/s390/vfio-ap.rst-769-\nDocumentation/arch/s390/vfio-ap.rst-770-3. Create the mediated devices needed to configure the AP matrixes for the\nDocumentation/arch/s390/vfio-ap.rst:771:   three guests and to provide an interface to the vfio_ap driver for\nDocumentation/arch/s390/vfio-ap.rst-772-   use by the guests::\nDocumentation/arch/s390/vfio-ap.rst-773-\nDocumentation/arch/s390/vfio-ap.rst:774:     /sys/devices/vfio_ap/matrix/\nDocumentation/arch/s390/vfio-ap.rst-775-     --- [mdev_supported_types]\nDocumentation/arch/s390/vfio-ap.rst:776:     ------ [vfio_ap-passthrough] (passthrough vfio_ap mediated device type)\nDocumentation/arch/s390/vfio-ap.rst-777-     --------- create\n--\nDocumentation/arch/s390/vfio-ap.rst-795-\nDocumentation/arch/s390/vfio-ap.rst:796:     /sys/devices/vfio_ap/matrix/\nDocumentation/arch/s390/vfio-ap.rst-797-     --- [mdev_supported_types]\nDocumentation/arch/s390/vfio-ap.rst:798:     ------ [vfio_ap-passthrough]\nDocumentation/arch/s390/vfio-ap.rst-799-     --------- [devices]\n--\nDocumentation/arch/s390/vfio-ap.rst-826-\nDocumentation/arch/s390/vfio-ap.rst:827:   Note *****: The vfio_ap mdevs do not persist across reboots unless the\nDocumentation/arch/s390/vfio-ap.rst-828-               mdevctl tool is used to create and persist them.\n--\nDocumentation/arch/s390/vfio-ap.rst-879-\nDocumentation/arch/s390/vfio-ap.rst:880:     - Must only be available to the vfio_ap device driver as specified in the\nDocumentation/arch/s390/vfio-ap.rst-881-       sysfs /sys/bus/ap/apmask and /sys/bus/ap/aqmask attribute files. If even\n--\nDocumentation/arch/s390/vfio-ap.rst-884-\nDocumentation/arch/s390/vfio-ap.rst:885:     - Must NOT be assigned to another vfio_ap mediated device. If even one APQN\nDocumentation/arch/s390/vfio-ap.rst:886:       is assigned to another vfio_ap mediated device, the operation will\nDocumentation/arch/s390/vfio-ap.rst-887-       terminate with an error (EBUSY).\n--\nDocumentation/arch/s390/vfio-ap.rst-905-\nDocumentation/arch/s390/vfio-ap.rst:906:     - Must only be available to the vfio_ap device driver as specified in the\nDocumentation/arch/s390/vfio-ap.rst-907-       sysfs /sys/bus/ap/apmask and /sys/bus/ap/aqmask attribute files. If even\n--\nDocumentation/arch/s390/vfio-ap.rst-910-\nDocumentation/arch/s390/vfio-ap.rst:911:     - Must NOT be assigned to another vfio_ap mediated device. If even one APQN\nDocumentation/arch/s390/vfio-ap.rst:912:       is assigned to another vfio_ap mediated device, the operation will\nDocumentation/arch/s390/vfio-ap.rst-913-       terminate with an error (EBUSY).\n--\nDocumentation/arch/s390/vfio-ap.rst-928-     /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on,apqi=on \\\nDocumentation/arch/s390/vfio-ap.rst:929:\t-device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid1 ...\nDocumentation/arch/s390/vfio-ap.rst-930-\n--\nDocumentation/arch/s390/vfio-ap.rst-933-     /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on,apqi=on \\\nDocumentation/arch/s390/vfio-ap.rst:934:\t-device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid2 ...\nDocumentation/arch/s390/vfio-ap.rst-935-\n--\nDocumentation/arch/s390/vfio-ap.rst-938-     /usr/bin/qemu-system-s390x ... -cpu host,ap=on,apqci=on,apft=on,apqi=on \\\nDocumentation/arch/s390/vfio-ap.rst:939:\t-device vfio-ap,sysfsdev=/sys/devices/vfio_ap/matrix/$uuid3 ...\nDocumentation/arch/s390/vfio-ap.rst-940-\nDocumentation/arch/s390/vfio-ap.rst:941:When the guest is shut down, the vfio_ap mediated devices may be removed.\nDocumentation/arch/s390/vfio-ap.rst-942-\nDocumentation/arch/s390/vfio-ap.rst:943:Using our example again, to remove the vfio_ap mediated device $uuid1::\nDocumentation/arch/s390/vfio-ap.rst-944-\nDocumentation/arch/s390/vfio-ap.rst:945:   /sys/devices/vfio_ap/matrix/\nDocumentation/arch/s390/vfio-ap.rst-946-      --- [mdev_supported_types]\nDocumentation/arch/s390/vfio-ap.rst:947:      ------ [vfio_ap-passthrough]\nDocumentation/arch/s390/vfio-ap.rst-948-      --------- [devices]\n--\nDocumentation/arch/s390/vfio-ap.rst=958=all of the steps starting with step 3 will have to be performed again. Note\nDocumentation/arch/s390/vfio-ap.rst:959:that the remove will fail if a guest using the vfio_ap mdev is still running.\nDocumentation/arch/s390/vfio-ap.rst-960-\nDocumentation/arch/s390/vfio-ap.rst:961:It is not necessary to remove a vfio_ap mdev, but one may want to\nDocumentation/arch/s390/vfio-ap.rst-962-remove it if no guest will use it during the remaining lifetime of the linux\nDocumentation/arch/s390/vfio-ap.rst:963:host. If the vfio_ap mdev is removed, one may want to also reconfigure\nDocumentation/arch/s390/vfio-ap.rst-964-the pool of adapters and queues reserved for use by the default drivers.\n--\nDocumentation/arch/s390/vfio-ap.rst=968=An adapter, domain or control domain may be hot plugged into a running KVM\nDocumentation/arch/s390/vfio-ap.rst:969:guest by assigning it to the vfio_ap mediated device being used by the guest if\nDocumentation/arch/s390/vfio-ap.rst-970-the following conditions are met:\n--\nDocumentation/arch/s390/vfio-ap.rst-976-  adapter being assigned and the APQIs of the domains assigned must reference a\nDocumentation/arch/s390/vfio-ap.rst:977:  queue device bound to the vfio_ap device driver.\nDocumentation/arch/s390/vfio-ap.rst-978-\n--\nDocumentation/arch/s390/vfio-ap.rst-980-  comprised of the APQI of the domain being assigned and the APIDs of the\nDocumentation/arch/s390/vfio-ap.rst:981:  adapters assigned must reference a queue device bound to the vfio_ap device\nDocumentation/arch/s390/vfio-ap.rst-982-  driver.\n--\nDocumentation/arch/s390/vfio-ap.rst=984=An adapter, domain or control domain may be hot unplugged from a running KVM\nDocumentation/arch/s390/vfio-ap.rst:985:guest by unassigning it from the vfio_ap mediated device being used by the\nDocumentation/arch/s390/vfio-ap.rst-986-guest.\n--\nDocumentation/arch/s390/vfio-ap.rst=990=Over-provisioning is defined herein as the assignment of adapters or domains to\nDocumentation/arch/s390/vfio-ap.rst:991:a vfio_ap mediated device that do not reference AP devices in the host's AP\nDocumentation/arch/s390/vfio-ap.rst-992-configuration. The idea here is that when the adapter or domain becomes\nDocumentation/arch/s390/vfio-ap.rst=993=available, it will be automatically hot-plugged into the KVM guest using\nDocumentation/arch/s390/vfio-ap.rst:994:the vfio_ap mediated device to which it is assigned as long as each new APQN\nDocumentation/arch/s390/vfio-ap.rst:995:resulting from plugging it in references a queue device bound to the vfio_ap\nDocumentation/arch/s390/vfio-ap.rst-996-device driver.\n--\nDocumentation/arch/s390/vfio-ap.rst=998=Driver Features\nDocumentation/arch/s390/vfio-ap.rst-999-===============\nDocumentation/arch/s390/vfio-ap.rst:1000:The vfio_ap driver exposes a sysfs file containing supported features.\nDocumentation/arch/s390/vfio-ap.rst-1001-This exists so third party tools (like Libvirt and mdevctl) can query the\n--\nDocumentation/arch/s390/vfio-ap.rst=1031=intervention by a system administrator. Before a KVM guest can be migrated,\nDocumentation/arch/s390/vfio-ap.rst:1032:the vfio_ap mediated device must be removed. Unfortunately, it can not be\nDocumentation/arch/s390/vfio-ap.rst:1033:removed manually (i.e., echo 1 \u003e /sys/devices/vfio_ap/matrix/$UUID/remove) while\nDocumentation/arch/s390/vfio-ap.rst-1034-the mdev is in use by a KVM guest. If the guest is being emulated by QEMU,\nDocumentation/arch/s390/vfio-ap.rst=1035=its mdev can be hot unplugged from the guest in one of two ways:\n--\nDocumentation/arch/s390/vfio-ap.rst-1059-\nDocumentation/arch/s390/vfio-ap.rst:1060:      For example, to hot unplug the vfio_ap mediated device identified on the\nDocumentation/arch/s390/vfio-ap.rst-1061-      qemu command line with 'id=hostdev0' from the guest named 'my-guest':\n--\nDocumentation/arch/s390/vfio-ap.rst-1066-\nDocumentation/arch/s390/vfio-ap.rst:1067:2. A vfio_ap mediated device can be hot unplugged by attaching the qemu monitor\nDocumentation/arch/s390/vfio-ap.rst-1068-   to the guest and using the following qemu monitor command:\n--\nDocumentation/arch/s390/vfio-ap.rst-1071-\nDocumentation/arch/s390/vfio-ap.rst:1072:      For example, to hot unplug the vfio_ap mediated device that was specified\nDocumentation/arch/s390/vfio-ap.rst-1073-      on the qemu command line with 'id=hostdev0' when the guest was started:\n--\nDocumentation/arch/s390/vfio-ap.rst=1077=After live migration of the KVM guest completes, an AP configuration can be\nDocumentation/arch/s390/vfio-ap.rst:1078:restored to the KVM guest by hot plugging a vfio_ap mediated device on the target\nDocumentation/arch/s390/vfio-ap.rst-1079-system into the guest in one of two ways:\n--\nDocumentation/arch/s390/vfio-ap.rst-1104-\nDocumentation/arch/s390/vfio-ap.rst:1105:      For example, to hot plug the vfio_ap mediated device\nDocumentation/arch/s390/vfio-ap.rst-1106-      62177883-f1bb-47f0-914d-32a22e3a8804 into the guest named 'my-guest' with\n--\nDocumentation/arch/s390/vfio-ap.rst-1110-      \"device_add vfio-ap,\\\nDocumentation/arch/s390/vfio-ap.rst:1111:      sysfsdev=/sys/devices/vfio_ap/matrix/62177883-f1bb-47f0-914d-32a22e3a8804,\\\nDocumentation/arch/s390/vfio-ap.rst-1112-      id=hostdev0\"\nDocumentation/arch/s390/vfio-ap.rst-1113-\nDocumentation/arch/s390/vfio-ap.rst:1114:2. A vfio_ap mediated device can be hot plugged by attaching the qemu monitor\nDocumentation/arch/s390/vfio-ap.rst-1115-   to the guest and using the following qemu monitor command:\n--\nDocumentation/arch/s390/vfio-ap.rst-1118-\nDocumentation/arch/s390/vfio-ap.rst:1119:      For example, to plug the vfio_ap mediated device\nDocumentation/arch/s390/vfio-ap.rst-1120-      62177883-f1bb-47f0-914d-32a22e3a8804 into the guest with the device-id\n--\nDocumentation/arch/s390/vfio-ap.rst-1123-         (QEMU) device-add \"vfio-ap,\\\nDocumentation/arch/s390/vfio-ap.rst:1124:         sysfsdev=/sys/devices/vfio_ap/matrix/62177883-f1bb-47f0-914d-32a22e3a8804,\\\nDocumentation/arch/s390/vfio-ap.rst-1125-         id=hostdev0\"\n--\nMAINTAINERS=23603=F:\tDocumentation/arch/s390/vfio-ap*\nMAINTAINERS:23604:F:\tdrivers/s390/crypto/vfio_ap*\nMAINTAINERS-23605-\n--\narch/s390/Kconfig=834=config VFIO_AP\n--\narch/s390/Kconfig-845-\t  To compile this driver as a module, choose M here: the module\narch/s390/Kconfig:846:\t  will be called vfio_ap.\narch/s390/Kconfig-847-\n--\narch/s390/kvm/priv.c=570=bool kvm_s390_is_gpa_in_memslot(struct kvm *kvm, gpa_t gpa)\n--\narch/s390/kvm/priv.c-573-}\narch/s390/kvm/priv.c:574:EXPORT_SYMBOL_FOR_MODULES(kvm_s390_is_gpa_in_memslot, \"vfio_ap\");\narch/s390/kvm/priv.c-575-#endif\n--\ndrivers/s390/crypto/Makefile=34=obj-$(CONFIG_PKEY_UV) += pkey-uv.o\n--\ndrivers/s390/crypto/Makefile-36-# adjunct processor matrix\ndrivers/s390/crypto/Makefile:37:vfio_ap-objs := vfio_ap_drv.o vfio_ap_ops.o\ndrivers/s390/crypto/Makefile:38:obj-$(CONFIG_VFIO_AP) += vfio_ap.o\n--\ndrivers/s390/crypto/vfio_ap_debug.h-19-#define VFIO_AP_DBF(...)\t\t\t\t\t\\\ndrivers/s390/crypto/vfio_ap_debug.h:20:\tdebug_sprintf_event(vfio_ap_dbf_info, ##__VA_ARGS__)\ndrivers/s390/crypto/vfio_ap_debug.h-21-#define VFIO_AP_DBF_ERR(...)\t\t\t\t\t\\\ndrivers/s390/crypto/vfio_ap_debug.h:22:\tdebug_sprintf_event(vfio_ap_dbf_info, DBF_ERR, ##__VA_ARGS__)\ndrivers/s390/crypto/vfio_ap_debug.h-23-#define VFIO_AP_DBF_WARN(...)\t\t\t\t\t\\\ndrivers/s390/crypto/vfio_ap_debug.h:24:\tdebug_sprintf_event(vfio_ap_dbf_info, DBF_WARN, ##__VA_ARGS__)\ndrivers/s390/crypto/vfio_ap_debug.h-25-#define VFIO_AP_DBF_INFO(...)\t\t\t\t\t\\\ndrivers/s390/crypto/vfio_ap_debug.h:26:\tdebug_sprintf_event(vfio_ap_dbf_info, DBF_INFO, ##__VA_ARGS__)\ndrivers/s390/crypto/vfio_ap_debug.h-27-#define VFIO_AP_DBF_DBG(...)\t\t\t\t\t\\\ndrivers/s390/crypto/vfio_ap_debug.h:28:\tdebug_sprintf_event(vfio_ap_dbf_info, DBF_DEBUG, ##__VA_ARGS__)\ndrivers/s390/crypto/vfio_ap_debug.h-29-\ndrivers/s390/crypto/vfio_ap_debug.h:30:extern debug_info_t *vfio_ap_dbf_info;\ndrivers/s390/crypto/vfio_ap_debug.h-31-\n--\ndrivers/s390/crypto/vfio_ap_drv.c-15-#include \u003casm/facility.h\u003e\ndrivers/s390/crypto/vfio_ap_drv.c:16:#include \"vfio_ap_private.h\"\ndrivers/s390/crypto/vfio_ap_drv.c:17:#include \"vfio_ap_debug.h\"\ndrivers/s390/crypto/vfio_ap_drv.c-18-\ndrivers/s390/crypto/vfio_ap_drv.c:19:#define VFIO_AP_ROOT_NAME \"vfio_ap\"\ndrivers/s390/crypto/vfio_ap_drv.c-20-#define VFIO_AP_DEV_NAME \"matrix\"\n--\ndrivers/s390/crypto/vfio_ap_drv.c=26=struct ap_matrix_dev *matrix_dev;\ndrivers/s390/crypto/vfio_ap_drv.c:27:debug_info_t *vfio_ap_dbf_info;\ndrivers/s390/crypto/vfio_ap_drv.c-28-\n--\ndrivers/s390/crypto/vfio_ap_drv.c=44=static struct ap_device_id ap_queue_ids[] = {\n--\ndrivers/s390/crypto/vfio_ap_drv.c-57-\ndrivers/s390/crypto/vfio_ap_drv.c:58:static struct ap_driver vfio_ap_drv = {\ndrivers/s390/crypto/vfio_ap_drv.c:59:\t.probe = vfio_ap_mdev_probe_queue,\ndrivers/s390/crypto/vfio_ap_drv.c:60:\t.remove = vfio_ap_mdev_remove_queue,\ndrivers/s390/crypto/vfio_ap_drv.c:61:\t.in_use = vfio_ap_mdev_resource_in_use,\ndrivers/s390/crypto/vfio_ap_drv.c:62:\t.on_config_changed = vfio_ap_on_cfg_changed,\ndrivers/s390/crypto/vfio_ap_drv.c:63:\t.on_scan_complete = vfio_ap_on_scan_complete,\ndrivers/s390/crypto/vfio_ap_drv.c-64-\t.ids = ap_queue_ids,\n--\ndrivers/s390/crypto/vfio_ap_drv.c-66-\ndrivers/s390/crypto/vfio_ap_drv.c:67:static void vfio_ap_matrix_dev_release(struct device *dev)\ndrivers/s390/crypto/vfio_ap_drv.c-68-{\n--\ndrivers/s390/crypto/vfio_ap_drv.c=79=static struct device_driver matrix_driver = {\ndrivers/s390/crypto/vfio_ap_drv.c:80:\t.name = \"vfio_ap\",\ndrivers/s390/crypto/vfio_ap_drv.c-81-\t.bus = \u0026matrix_bus,\n--\ndrivers/s390/crypto/vfio_ap_drv.c-85-\ndrivers/s390/crypto/vfio_ap_drv.c:86:static int vfio_ap_matrix_dev_create(void)\ndrivers/s390/crypto/vfio_ap_drv.c-87-{\n--\ndrivers/s390/crypto/vfio_ap_drv.c-118-\tmatrix_dev-\u003edevice.bus = \u0026matrix_bus;\ndrivers/s390/crypto/vfio_ap_drv.c:119:\tmatrix_dev-\u003edevice.release = vfio_ap_matrix_dev_release;\ndrivers/s390/crypto/vfio_ap_drv.c:120:\tmatrix_dev-\u003evfio_ap_drv = \u0026vfio_ap_drv;\ndrivers/s390/crypto/vfio_ap_drv.c-121-\n--\ndrivers/s390/crypto/vfio_ap_drv.c-142-\ndrivers/s390/crypto/vfio_ap_drv.c:143:static void vfio_ap_matrix_dev_destroy(void)\ndrivers/s390/crypto/vfio_ap_drv.c-144-{\n--\ndrivers/s390/crypto/vfio_ap_drv.c-152-\ndrivers/s390/crypto/vfio_ap_drv.c:153:static int __init vfio_ap_dbf_info_init(void)\ndrivers/s390/crypto/vfio_ap_drv.c-154-{\ndrivers/s390/crypto/vfio_ap_drv.c:155:\tvfio_ap_dbf_info = debug_register(\"vfio_ap\", 1, 1,\ndrivers/s390/crypto/vfio_ap_drv.c-156-\t\t\t\t\t  DBF_MAX_SPRINTF_ARGS * sizeof(long));\ndrivers/s390/crypto/vfio_ap_drv.c-157-\ndrivers/s390/crypto/vfio_ap_drv.c:158:\tif (!vfio_ap_dbf_info)\ndrivers/s390/crypto/vfio_ap_drv.c-159-\t\treturn -ENOENT;\ndrivers/s390/crypto/vfio_ap_drv.c-160-\ndrivers/s390/crypto/vfio_ap_drv.c:161:\tdebug_register_view(vfio_ap_dbf_info, \u0026debug_sprintf_view);\ndrivers/s390/crypto/vfio_ap_drv.c:162:\tdebug_set_level(vfio_ap_dbf_info, DBF_WARN);\ndrivers/s390/crypto/vfio_ap_drv.c-163-\n--\ndrivers/s390/crypto/vfio_ap_drv.c-166-\ndrivers/s390/crypto/vfio_ap_drv.c:167:static int __init vfio_ap_init(void)\ndrivers/s390/crypto/vfio_ap_drv.c-168-{\n--\ndrivers/s390/crypto/vfio_ap_drv.c-170-\ndrivers/s390/crypto/vfio_ap_drv.c:171:\tret = vfio_ap_dbf_info_init();\ndrivers/s390/crypto/vfio_ap_drv.c-172-\tif (ret)\n--\ndrivers/s390/crypto/vfio_ap_drv.c-178-\ndrivers/s390/crypto/vfio_ap_drv.c:179:\tret = vfio_ap_matrix_dev_create();\ndrivers/s390/crypto/vfio_ap_drv.c-180-\tif (ret)\n--\ndrivers/s390/crypto/vfio_ap_drv.c-182-\ndrivers/s390/crypto/vfio_ap_drv.c:183:\tret = ap_driver_register(\u0026vfio_ap_drv, THIS_MODULE, VFIO_AP_DRV_NAME);\ndrivers/s390/crypto/vfio_ap_drv.c-184-\tif (ret) {\ndrivers/s390/crypto/vfio_ap_drv.c:185:\t\tvfio_ap_matrix_dev_destroy();\ndrivers/s390/crypto/vfio_ap_drv.c-186-\t\treturn ret;\n--\ndrivers/s390/crypto/vfio_ap_drv.c-188-\ndrivers/s390/crypto/vfio_ap_drv.c:189:\tret = vfio_ap_mdev_register();\ndrivers/s390/crypto/vfio_ap_drv.c-190-\tif (ret) {\ndrivers/s390/crypto/vfio_ap_drv.c:191:\t\tap_driver_unregister(\u0026vfio_ap_drv);\ndrivers/s390/crypto/vfio_ap_drv.c:192:\t\tvfio_ap_matrix_dev_destroy();\ndrivers/s390/crypto/vfio_ap_drv.c-193-\n--\ndrivers/s390/crypto/vfio_ap_drv.c-199-\ndrivers/s390/crypto/vfio_ap_drv.c:200:static void __exit vfio_ap_exit(void)\ndrivers/s390/crypto/vfio_ap_drv.c-201-{\ndrivers/s390/crypto/vfio_ap_drv.c:202:\tvfio_ap_mdev_unregister();\ndrivers/s390/crypto/vfio_ap_drv.c:203:\tap_driver_unregister(\u0026vfio_ap_drv);\ndrivers/s390/crypto/vfio_ap_drv.c:204:\tvfio_ap_matrix_dev_destroy();\ndrivers/s390/crypto/vfio_ap_drv.c:205:\tdebug_unregister(vfio_ap_dbf_info);\ndrivers/s390/crypto/vfio_ap_drv.c-206-}\ndrivers/s390/crypto/vfio_ap_drv.c-207-\ndrivers/s390/crypto/vfio_ap_drv.c:208:module_init(vfio_ap_init);\n\n"
}

gemini-3.1-pro-preview

							input: 39449
							output: 26
							thoughts: 156

**Analyzing the Potential for VFIO-AP Exploitation via Syzkaller**

Okay, let's break this down. My initial observation is that the `vfio_ap` module seems to register a matrix device, and then an mdev driver. That's the setup. And Syzkaller, which I'm very familiar with, can create these mdevs, which immediately raises a critical question: Can we reach and exploit `vfio_ap` functionality even without the presence of physical AP hardware?

My hypothesis rests on that initial question. I'm going to dig a little deeper, I'm going to consider the `vfio_ap_matrix_dev_create` function. I see that it appears to succeed even if the `test_facility(12)` check fails. That's a key observation, something that may be important. The driver then registers itself which looks very interesting. So, can Syzkaller create a `vfio_ap` mdev. This is the crucial next step.

I know Syzkaller has descriptions for mdevs in files like `sys/linux/sysfs_mdev.txt`. I need to confirm whether Syzkaller has descriptions for `vfio_ap` specifically, because if it does, it's very likely we have a potential attack vector to investigate. That's where I need to start my search.

{
  "Expression": "vfio_ap",
  "PathPrefix": "sys/"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

							input: 39938
							output: 23
							thoughts: 391

**My Analysis of the Patch's Worthiness for Fuzzing**

Okay, so the prompt just threw a curveball. It's reminding me that I absolutely *cannot* use my usual `grepper` on anything that's `sys/*` or has `syz_` in it because that's all Syzkaller pseudo-syscall stuff and won't be in the actual kernel. Fine. Makes sense. But wait a sec... I don't see this `syz-grepper` in my available tools. Guess I'll have to use my brain instead!

Let's think. The patch modifies `vfio_ap_mdev_set_kvm` and `vfio_ap_mdev_unset_kvm`. Those are, if I remember correctly, related to VFIO device setup and teardown – when a VFIO device is opened or closed. The real question is, can Syzkaller *actually* create and interact with a VFIO AP device in a standard QEMU environment?

If Syzkaller can generate the code to create an mdev, it can open it as well. That depends on whether the `vfio_ap` driver is enabled in typical configurations.

Now, the prompt brings up the "WorthFuzzing=false" scenario: unreachable code in virtualized environments. It explicitly mentions things like USB gadget, MAC80211 HWsim, or *vendor-specific* hardware like PCIe switches or GPUs that need a *physical* card, which isn't emulated by QEMU. That's the key.

VFIO AP is for passing through *physical* AP cards, isn't it? Does it need physical hardware to be present to even create an mdev? I should check `vfio_ap_mdev_probe` and `vfio_ap_mdev_init_dev`. That will give me the answer.

{
  "Expression": "vfio_ap_mdev_probe"
}

{
  "Output": "drivers/s390/crypto/vfio_ap_drv.c=58=static struct ap_driver vfio_ap_drv = {\ndrivers/s390/crypto/vfio_ap_drv.c:59:\t.probe = vfio_ap_mdev_probe_queue,\ndrivers/s390/crypto/vfio_ap_drv.c-60-\t.remove = vfio_ap_mdev_remove_queue,\n--\ndrivers/s390/crypto/vfio_ap_ops.c=783=static int vfio_ap_mdev_init_dev(struct vfio_device *vdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-796-\ndrivers/s390/crypto/vfio_ap_ops.c:797:static int vfio_ap_mdev_probe(struct mdev_device *mdev)\ndrivers/s390/crypto/vfio_ap_ops.c-798-{\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2369=static struct mdev_driver vfio_ap_matrix_driver = {\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2377-\t},\ndrivers/s390/crypto/vfio_ap_ops.c:2378:\t.probe = vfio_ap_mdev_probe,\ndrivers/s390/crypto/vfio_ap_ops.c-2379-\t.remove = vfio_ap_mdev_remove,\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2405=void vfio_ap_mdev_unregister(void)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2410-\ndrivers/s390/crypto/vfio_ap_ops.c:2411:int vfio_ap_mdev_probe_queue(struct ap_device *apdev)\ndrivers/s390/crypto/vfio_ap_ops.c-2412-{\n--\ndrivers/s390/crypto/vfio_ap_private.h=156=void vfio_ap_mdev_unregister(void);\ndrivers/s390/crypto/vfio_ap_private.h-157-\ndrivers/s390/crypto/vfio_ap_private.h:158:int vfio_ap_mdev_probe_queue(struct ap_device *queue);\ndrivers/s390/crypto/vfio_ap_private.h-159-void vfio_ap_mdev_remove_queue(struct ap_device *queue);\n"
}

gemini-3.1-pro-preview

							input: 41450
							output: 45
							thoughts: 70

Here's my summary, as I understand the situation:

**Probing the Crypto Hardware with VFIO-AP**

Okay, so I'm digging into the VFIO-AP implementation for crypto hardware on s390 systems. The key is to understand how the system discovers and initializes the devices. My immediate focus is on the `vfio_ap_mdev_probe` function. That's the entry point, the first place the driver gets a shot at a new mdev, so it's critical to see what it's doing. I'm also going to track how `vfio_ap_mdev_init_dev` fits in as it is the follow-up step. I’m thinking they're probably both defined in `drivers/s390/crypto/vfio_ap_ops.c`. I need to figure out how these functions are connected and the logic flow. This seems to be the core of how the VFIO driver interacts with the underlying AP hardware and how it handles the mediated device, as well as how the hardware is detected. This is a crucial area to understanding the overall architecture and how the system virtualizes the crypto hardware to the user.

{
  "File": "drivers/s390/crypto/vfio_ap_ops.c",
  "FirstLine": 783,
  "LineCount": 50
}

{
  "Contents": " 783:\tstatic int vfio_ap_mdev_init_dev(struct vfio_device *vdev)\n 784:\t{\n 785:\t\tstruct ap_matrix_mdev *matrix_mdev =\n 786:\t\t\tcontainer_of(vdev, struct ap_matrix_mdev, vdev);\n 787:\t\n 788:\t\tmatrix_mdev-\u003emdev = to_mdev_device(vdev-\u003edev);\n 789:\t\tvfio_ap_matrix_init(\u0026matrix_dev-\u003einfo, \u0026matrix_mdev-\u003ematrix);\n 790:\t\tmatrix_mdev-\u003epqap_hook = handle_pqap;\n 791:\t\tvfio_ap_matrix_init(\u0026matrix_dev-\u003einfo, \u0026matrix_mdev-\u003eshadow_apcb);\n 792:\t\thash_init(matrix_mdev-\u003eqtable.queues);\n 793:\t\n 794:\t\treturn 0;\n 795:\t}\n 796:\t\n 797:\tstatic int vfio_ap_mdev_probe(struct mdev_device *mdev)\n 798:\t{\n 799:\t\tstruct ap_matrix_mdev *matrix_mdev;\n 800:\t\tint ret;\n 801:\t\n 802:\t\tmatrix_mdev = vfio_alloc_device(ap_matrix_mdev, vdev, \u0026mdev-\u003edev,\n 803:\t\t\t\t\t\t\u0026vfio_ap_matrix_dev_ops);\n 804:\t\tif (IS_ERR(matrix_mdev))\n 805:\t\t\treturn PTR_ERR(matrix_mdev);\n 806:\t\n 807:\t\tret = vfio_register_emulated_iommu_dev(\u0026matrix_mdev-\u003evdev);\n 808:\t\tif (ret)\n 809:\t\t\tgoto err_put_vdev;\n 810:\t\tmatrix_mdev-\u003ereq_trigger = NULL;\n 811:\t\tmatrix_mdev-\u003ecfg_chg_trigger = NULL;\n 812:\t\tdev_set_drvdata(\u0026mdev-\u003edev, matrix_mdev);\n 813:\t\tmutex_lock(\u0026matrix_dev-\u003emdevs_lock);\n 814:\t\tlist_add(\u0026matrix_mdev-\u003enode, \u0026matrix_dev-\u003emdev_list);\n 815:\t\tmutex_unlock(\u0026matrix_dev-\u003emdevs_lock);\n 816:\t\treturn 0;\n 817:\t\n 818:\terr_put_vdev:\n 819:\t\tvfio_put_device(\u0026matrix_mdev-\u003evdev);\n 820:\t\treturn ret;\n 821:\t}\n 822:\t\n 823:\tstatic void vfio_ap_mdev_link_queue(struct ap_matrix_mdev *matrix_mdev,\n 824:\t\t\t\t\t    struct vfio_ap_queue *q)\n 825:\t{\n 826:\t\tif (!q || vfio_ap_mdev_get_queue(matrix_mdev, q-\u003eapqn))\n 827:\t\t\treturn;\n 828:\t\n 829:\t\tq-\u003ematrix_mdev = matrix_mdev;\n 830:\t\thash_add(matrix_mdev-\u003eqtable.queues, \u0026q-\u003emdev_qnode, q-\u003eapqn);\n 831:\t}\n 832:\t\n"
}

gemini-3.1-pro-preview

							input: 42705
							output: 46
							thoughts: 78

Okay, let's break this down.

**Understanding mdev Creation and VFIO Interaction**

Right, so I'm focusing on how this mdev (mediated device) is being created. It's becoming clear that the process *doesn't* necessarily depend on having any pre-existing physical AP (Accelerated Processing) queues. That's interesting. The key here seems to be the allocation of this `ap_matrix_mdev` structure and its subsequent registration. That's the core of the mdev itself.

The real magic, the part where the virtual device actually hooks into KVM, seems to happen later, specifically when `vfio_ap_mdev_set_kvm` is called. That makes sense; it's the point where we're actually associating the virtual device with the VFIO infrastructure, linking it to a KVM instance.

To get a clearer picture of that linkage, I need to check how the device is opened and configured. Let's delve into the function `vfio_ap_mdev_open_device` to see precisely how this happens. That's where the rubber meets the road, so to speak. Understanding the flow from allocation, registration to opening the device should give me a good understanding of the entire process.

{
  "File": "drivers/s390/crypto/vfio_ap_ops.c",
  "FirstLine": 2048,
  "LineCount": 50
}

{
  "Contents": "2048:\tstatic int vfio_ap_mdev_open_device(struct vfio_device *vdev)\n2049:\t{\n2050:\t\tstruct ap_matrix_mdev *matrix_mdev =\n2051:\t\t\tcontainer_of(vdev, struct ap_matrix_mdev, vdev);\n2052:\t\n2053:\t\tif (!vdev-\u003ekvm)\n2054:\t\t\treturn -EINVAL;\n2055:\t\n2056:\t\treturn vfio_ap_mdev_set_kvm(matrix_mdev, vdev-\u003ekvm);\n2057:\t}\n2058:\t\n2059:\tstatic void vfio_ap_mdev_close_device(struct vfio_device *vdev)\n2060:\t{\n2061:\t\tstruct ap_matrix_mdev *matrix_mdev =\n2062:\t\t\tcontainer_of(vdev, struct ap_matrix_mdev, vdev);\n2063:\t\n2064:\t\tvfio_ap_mdev_unset_kvm(matrix_mdev);\n2065:\t}\n2066:\t\n2067:\tstatic void vfio_ap_mdev_request(struct vfio_device *vdev, unsigned int count)\n2068:\t{\n2069:\t\tstruct device *dev = vdev-\u003edev;\n2070:\t\tstruct ap_matrix_mdev *matrix_mdev;\n2071:\t\n2072:\t\tmatrix_mdev = container_of(vdev, struct ap_matrix_mdev, vdev);\n2073:\t\n2074:\t\tget_update_locks_for_mdev(matrix_mdev);\n2075:\t\n2076:\t\tif (matrix_mdev-\u003ekvm) {\n2077:\t\t\tkvm_arch_crypto_clear_masks(matrix_mdev-\u003ekvm);\n2078:\t\t\tsignal_guest_ap_cfg_changed(matrix_mdev);\n2079:\t\t}\n2080:\t\n2081:\t\tif (matrix_mdev-\u003ereq_trigger) {\n2082:\t\t\tif (!(count % 10))\n2083:\t\t\t\tdev_notice_ratelimited(dev,\n2084:\t\t\t\t\t\t       \"Relaying device request to user (#%u)\\n\",\n2085:\t\t\t\t\t\t       count);\n2086:\t\n2087:\t\t\teventfd_signal(matrix_mdev-\u003ereq_trigger);\n2088:\t\t} else if (count == 0) {\n2089:\t\t\tdev_notice(dev,\n2090:\t\t\t\t   \"No device request registered, blocked until released by user\\n\");\n2091:\t\t}\n2092:\t\n2093:\t\trelease_update_locks_for_mdev(matrix_mdev);\n2094:\t}\n2095:\t\n2096:\tstatic int vfio_ap_mdev_get_device_info(unsigned long arg)\n2097:\t{\n"
}

gemini-3.1-pro-preview

							input: 43895
							output: 16
							thoughts: 349

**Reaching the VFIO AP Locking Logic**

Okay, so I'm looking at this patch and tracing the code flow. It seems `vfio_ap_mdev_open_device` calls `vfio_ap_mdev_set_kvm`. That's the entry point. The crucial part here is how we get there. It's triggered by creating and opening a VFIO device. Syzkaller, from what I recall, has descriptions for VFIO and can create mdevs, according to `sys/linux/vfio.txt` or similar. I'm pretty sure it supports VFIO and can create these mdevs, which means `vfio_ap_mdev_set_kvm` is definitely reachable.

The patch itself targets `vfio_ap_mdev_set_kvm`, and its counterpart, `vfio_ap_mdev_unset_kvm`, along with `get_update_locks_for_kvm` and `release_update_locks_for_kvm`. Given the functions are explicitly mentioned, that confirms these are all reachable. Since the patch modifies these functions, it's pretty clear this is addressing locking issues or, at the very least, altering the locking behavior.

Given the modifications to core locking logic within VFIO AP, this is absolutely worth fuzzing. The question that remains is whether there are any hardware restrictions that need to be met. Thankfully, there are not; since `vfio_ap_mdev_probe` succeeds without a physical AP, `vfio_ap_mdev_open_device` does not have any further restrictions.

However, `vfio_ap_mdev_set_kvm` does check `kvm->arch.crypto.crycbd`. So I'm going to dig deeper and look into when and how that is set.

{
  "Expression": "crycbd"
}

{
  "Output": "arch/s390/include/asm/kvm_host.h=530=struct kvm_s390_crypto {\n--\narch/s390/include/asm/kvm_host.h-533-\tcrypto_hook *pqap_hook;\narch/s390/include/asm/kvm_host.h:534:\t__u32 crycbd;\narch/s390/include/asm/kvm_host.h-535-\t__u8 aes_kw;\n--\narch/s390/include/asm/kvm_host_types.h=137=struct kvm_s390_sie_block {\n--\narch/s390/include/asm/kvm_host_types.h-305-#define CRYCB_FORMAT2 0x00000003\narch/s390/include/asm/kvm_host_types.h:306:\t__u32\tcrycbd;\t\t\t/* 0x00fc */\narch/s390/include/asm/kvm_host_types.h-307-\t__u64\tgcr[16];\t\t/* 0x0100 */\n--\narch/s390/kvm/kvm-s390.c=3121=static void kvm_s390_set_crycb_format(struct kvm *kvm)\narch/s390/kvm/kvm-s390.c-3122-{\narch/s390/kvm/kvm-s390.c:3123:\tkvm-\u003earch.crypto.crycbd = virt_to_phys(kvm-\u003earch.crypto.crycb);\narch/s390/kvm/kvm-s390.c-3124-\narch/s390/kvm/kvm-s390.c-3125-\t/* Clear the CRYCB format bits - i.e., set format 0 by default */\narch/s390/kvm/kvm-s390.c:3126:\tkvm-\u003earch.crypto.crycbd \u0026= ~(CRYCB_FORMAT_MASK);\narch/s390/kvm/kvm-s390.c-3127-\n--\narch/s390/kvm/kvm-s390.c-3132-\tif (kvm_s390_apxa_installed())\narch/s390/kvm/kvm-s390.c:3133:\t\tkvm-\u003earch.crypto.crycbd |= CRYCB_FORMAT2;\narch/s390/kvm/kvm-s390.c-3134-\telse\narch/s390/kvm/kvm-s390.c:3135:\t\tkvm-\u003earch.crypto.crycbd |= CRYCB_FORMAT1;\narch/s390/kvm/kvm-s390.c-3136-}\n--\narch/s390/kvm/kvm-s390.c=3153=void kvm_arch_crypto_set_masks(struct kvm *kvm, unsigned long *apm,\n--\narch/s390/kvm/kvm-s390.c-3159-\narch/s390/kvm/kvm-s390.c:3160:\tswitch (kvm-\u003earch.crypto.crycbd \u0026 CRYCB_FORMAT_MASK) {\narch/s390/kvm/kvm-s390.c-3161-\tcase CRYCB_FORMAT2: /* APCB1 use 256 bits */\n--\narch/s390/kvm/kvm-s390.c=3642=static void kvm_s390_vcpu_crypto_setup(struct kvm_vcpu *vcpu)\n--\narch/s390/kvm/kvm-s390.c-3650-\narch/s390/kvm/kvm-s390.c:3651:\tvcpu-\u003earch.sie_block-\u003ecrycbd = vcpu-\u003ekvm-\u003earch.crypto.crycbd;\narch/s390/kvm/kvm-s390.c-3652-\tvcpu-\u003earch.sie_block-\u003eecb3 \u0026= ~(ECB3_AES | ECB3_DEA);\n--\narch/s390/kvm/priv.c=592=static int handle_pqap(struct kvm_vcpu *vcpu)\n--\narch/s390/kvm/priv.c-630-\t/* APXA not installed and APID greater 64 or APQI greater 16 */\narch/s390/kvm/priv.c:631:\tif (!(vcpu-\u003ekvm-\u003earch.crypto.crycbd \u0026 0x02) \u0026\u0026 (reg0 \u0026 0x0000c0f0UL))\narch/s390/kvm/priv.c-632-\t\treturn kvm_s390_inject_program_int(vcpu, PGM_SPECIFICATION);\n--\narch/s390/kvm/vsie.c=318=static int shadow_crycb(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)\n--\narch/s390/kvm/vsie.c-321-\tstruct kvm_s390_sie_block *scb_o = vsie_page-\u003escb_o;\narch/s390/kvm/vsie.c:322:\tconst uint32_t crycbd_o = READ_ONCE(scb_o-\u003ecrycbd);\narch/s390/kvm/vsie.c:323:\tconst u32 crycb_addr = crycbd_o \u0026 0x7ffffff8U;\narch/s390/kvm/vsie.c-324-\tunsigned long *b1, *b2;\n--\narch/s390/kvm/vsie.c-329-\tint key_msk = test_kvm_facility(vcpu-\u003ekvm, 76);\narch/s390/kvm/vsie.c:330:\tint fmt_o = crycbd_o \u0026 CRYCB_FORMAT_MASK;\narch/s390/kvm/vsie.c:331:\tint fmt_h = vcpu-\u003earch.sie_block-\u003ecrycbd \u0026 CRYCB_FORMAT_MASK;\narch/s390/kvm/vsie.c-332-\tint ret = 0;\narch/s390/kvm/vsie.c-333-\narch/s390/kvm/vsie.c:334:\tscb_s-\u003ecrycbd = 0;\narch/s390/kvm/vsie.c-335-\n--\narch/s390/kvm/vsie.c-388-\t}\narch/s390/kvm/vsie.c:389:\tscb_s-\u003ecrycbd = (u32)virt_to_phys(\u0026vsie_page-\u003ecrycb) | CRYCB_FORMAT2;\narch/s390/kvm/vsie.c-390-\treturn 0;\n--\ndrivers/s390/crypto/vfio_ap_ops.c=1828=static int vfio_ap_mdev_set_kvm(struct ap_matrix_mdev *matrix_mdev,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1830-{\ndrivers/s390/crypto/vfio_ap_ops.c:1831:\tif (kvm-\u003earch.crypto.crycbd) {\ndrivers/s390/crypto/vfio_ap_ops.c-1832-\t\tget_update_locks_for_kvm(kvm);\n--\ndrivers/s390/crypto/vfio_ap_ops.c=1879=static void vfio_ap_mdev_unset_kvm(struct ap_matrix_mdev *matrix_mdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1882-\ndrivers/s390/crypto/vfio_ap_ops.c:1883:\tif (kvm \u0026\u0026 kvm-\u003earch.crypto.crycbd) {\ndrivers/s390/crypto/vfio_ap_ops.c-1884-\t\tget_update_locks_for_kvm(kvm);\n--\ntools/testing/selftests/kvm/include/s390/sie.h=20=struct kvm_s390_sie_block {\n--\ntools/testing/selftests/kvm/include/s390/sie.h-213-#define CRYCB_FORMAT2\t\t0x00000003\ntools/testing/selftests/kvm/include/s390/sie.h:214:\t__u32\tcrycbd;\t\t\t/* 0x00fc */\ntools/testing/selftests/kvm/include/s390/sie.h-215-\t__u64\tgcr[16];\t\t/* 0x0100 */\n"
}

gemini-3.1-pro-preview

							input: 47023
							output: 19
							thoughts: 710

**Analyzing the Patch's Impact on VFIO-AP and KVM Integration**

Okay, let's break this down. My initial thought is: `kvm_s390_set_crycb_format` sets the `crycbd` structure. That function is called during the KVM VM initialization via `kvm_s390_crypto_init`, and ultimately from `kvm_arch_init_vm`. This means `kvm->arch.crypto.crycbd` is populated when a KVM VM instance is created. That's key because `vfio_ap_mdev_set_kvm` *should* execute its core logic if a `kvm` pointer is passed in. Right, and `vfio_ap_mdev_set_kvm` is *called* from `vfio_ap_mdev_open_device` and it uses `vdev->kvm`, so `vdev->kvm` becomes assigned when a VFIO device is connected to a KVM instance. So, using Syzkaller, which can open the VFIO device and uses ioctls like `KVM_DEV_VFIO_GROUP_ADD`, we can reach this code path and test it within a virtualized setup. Good.

Now, let's revisit the patch itself. It's adding `pqap_hook_rwsem` to `get_update_locks_for_kvm` and also `release_update_locks_for_kvm`. The patch modifies `vfio_ap_mdev_set_kvm` in a way that suggests a functional change to the locking and state management logic. The previous checks for `crycbd` are gone. This indicates a significant change in how the `pqap_hook` is handled. Specifically, it seems to be ensuring that the hook is only set when not already set for another device attached to the same KVM instance. The `list_for_each_entry` loop is removed, and replaced with a check of `kvm->arch.crypto.pqap_hook`. So that's now a single check.

This is all *definitely* worth fuzzing. The lock changes, the state management tweaks – these are ripe for concurrency bugs or unexpected behavior. We'll need to focus on interactions between multiple VFIO AP devices, KVM, and the AP hardware.

As for configuration, we need to ensure that `CONFIG_VFIO_AP` is enabled. Let's quickly double-check that in `arch/s390/Kconfig` to be sure. Alright, now we know what to test, and the configurations required. Time to set up the fuzzing environment.

{
  "Expression": "config VFIO_AP"
}

{
  "Output": "arch/s390/Kconfig=823=config VFIO_CCW\n--\narch/s390/Kconfig-833-\narch/s390/Kconfig:834:config VFIO_AP\narch/s390/Kconfig-835-\tdef_tristate n\n"
}

gemini-3.1-pro-preview

							input: 48422
							output: 37
							thoughts: 22

Here's my analysis of the provided text, rendered as a first-person expert summary:

**Diving into the s390 Architecture Configuration**

Okay, so we're looking at the `arch/s390/Kconfig` file, specifically around line 834. I'm going to assume this section likely relates to some feature or configuration option within the s390 architecture. Given the context of a Kconfig file, it's probably defining a conditional build option, a hardware feature setting, or maybe even a driver configuration related to the IBM mainframe architecture. I'll need to carefully examine the surrounding code to understand the dependencies, default values, and help text associated with this specific configuration item. It could be something straightforward, or it might require a deeper understanding of the hardware capabilities, firmware interactions, or specific kernel subsystems within the s390 environment. Let's see what we can find.

{
  "File": "arch/s390/Kconfig",
  "FirstLine": 830,
  "LineCount": 20
}

{
  "Contents": " 830:\t\n 831:\t\t  To compile this driver as a module, choose M here: the\n 832:\t\t  module will be called vfio_ccw.\n 833:\t\n 834:\tconfig VFIO_AP\n 835:\t\tdef_tristate n\n 836:\t\tprompt \"VFIO support for AP devices\"\n 837:\t\tdepends on KVM\n 838:\t\tdepends on VFIO\n 839:\t\tdepends on AP\n 840:\t\tselect VFIO_MDEV\n 841:\t\thelp\n 842:\t\t  This driver grants access to Adjunct Processor (AP) devices\n 843:\t\t  via the VFIO mediated device interface.\n 844:\t\n 845:\t\t  To compile this driver as a module, choose M here: the module\n 846:\t\t  will be called vfio_ap.\n 847:\t\n 848:\tendmenu\n 849:\t\n"
}

gemini-3.1-pro-preview

							input: 48940
							output: 16
							thoughts: 49

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

**VFIO-AP Configuration Conundrum**

Right, so to get this working, it seems that `CONFIG_VFIO_AP` is absolutely essential. Okay, obvious start. But, I need to figure out its dependencies to properly configure everything. It looks like it directly depends on `KVM`, `VFIO`, and `AP`. That's a reasonable set, I can work with that, makes sense to me. The interesting part is `AP`. Is `AP` referring to `CONFIG_ZCRYPT`? I'll need to double-check that definition in the kernel config... Let me go and dig that up.

{
  "Expression": "config AP"
}

{
  "Output": "Documentation/admin-guide/bootconfig.rst=287=to initrd image, user can notice it before boot.\n--\nDocumentation/admin-guide/bootconfig.rst-289-\nDocumentation/admin-guide/bootconfig.rst:290:Bootconfig APIs\nDocumentation/admin-guide/bootconfig.rst-291-===============\n--\narch/m68k/Kconfig.machine=29=config MAC\n--\narch/m68k/Kconfig.machine-40-\narch/m68k/Kconfig.machine:41:config APOLLO\narch/m68k/Kconfig.machine-42-\tbool \"Apollo support\"\n--\narch/powerpc/platforms/44x/Kconfig=291=config 476FPE\n--\narch/powerpc/platforms/44x/Kconfig-294-\narch/powerpc/platforms/44x/Kconfig:295:config APM821xx\narch/powerpc/platforms/44x/Kconfig-296-\tbool\n--\narch/s390/Kconfig=785=config EADM_SCH\n--\narch/s390/Kconfig-795-\narch/s390/Kconfig:796:config AP\narch/s390/Kconfig-797-\tdef_tristate y\n--\narch/s390/Kconfig-808-\narch/s390/Kconfig:809:config AP_DEBUG\narch/s390/Kconfig-810-\tdef_bool n\n--\narch/s390/Kconfig=885=config CMM_IUCV\n--\narch/s390/Kconfig-892-\narch/s390/Kconfig:893:config APPLDATA_BASE\narch/s390/Kconfig-894-\tdef_bool n\n--\narch/s390/Kconfig-908-\narch/s390/Kconfig:909:config APPLDATA_MEM\narch/s390/Kconfig-910-\tdef_tristate m\n--\narch/s390/Kconfig-925-\narch/s390/Kconfig:926:config APPLDATA_OS\narch/s390/Kconfig-927-\tdef_tristate m\n--\narch/s390/Kconfig-940-\narch/s390/Kconfig:941:config APPLDATA_NET_SUM\narch/s390/Kconfig-942-\tdef_tristate m\n--\narch/x86/Kconfig=2741=config X86_APM_BOOT\n--\narch/x86/Kconfig-2744-\narch/x86/Kconfig:2745:menuconfig APM\narch/x86/Kconfig-2746-\ttristate \"APM (Advanced Power Management) BIOS support\"\n--\narch/x86/Kconfig=2799=if APM\narch/x86/Kconfig-2800-\narch/x86/Kconfig:2801:config APM_IGNORE_USER_SUSPEND\narch/x86/Kconfig-2802-\tbool \"Ignore USER SUSPEND\"\n--\narch/x86/Kconfig-2807-\narch/x86/Kconfig:2808:config APM_DO_ENABLE\narch/x86/Kconfig-2809-\tbool \"Enable PM at boot time\"\n--\narch/x86/Kconfig-2824-\narch/x86/Kconfig:2825:config APM_CPU_IDLE\narch/x86/Kconfig-2826-\tdepends on CPU_IDLE\n--\narch/x86/Kconfig-2836-\narch/x86/Kconfig:2837:config APM_DISPLAY_BLANK\narch/x86/Kconfig-2838-\tbool \"Enable console blanking using APM\"\n--\narch/x86/Kconfig-2849-\narch/x86/Kconfig:2850:config APM_ALLOW_INTS\narch/x86/Kconfig-2851-\tbool \"Allow interrupts during APM BIOS calls\"\n--\ndrivers/char/Kconfig=213=config XILINX_HWICAP\n--\ndrivers/char/Kconfig-222-\ndrivers/char/Kconfig:223:config APPLICOM\ndrivers/char/Kconfig-224-\ttristate \"Applicom intelligent fieldbus card support\"\n--\ndrivers/clk/qcom/Kconfig=290=config QCOM_CLK_RPMH\n--\ndrivers/clk/qcom/Kconfig-298-\ndrivers/clk/qcom/Kconfig:299:config APQ_GCC_8084\ndrivers/clk/qcom/Kconfig-300-\ttristate \"APQ8084 Global Clock Controller\"\n--\ndrivers/clk/qcom/Kconfig-307-\ndrivers/clk/qcom/Kconfig:308:config APQ_MMCC_8084\ndrivers/clk/qcom/Kconfig-309-\ttristate \"APQ8084 Multimedia Clock Controller\"\n--\ndrivers/dma/Kconfig=78=config AMCC_PPC440SPE_ADMA\n--\ndrivers/dma/Kconfig-87-\ndrivers/dma/Kconfig:88:config APPLE_ADMAC\ndrivers/dma/Kconfig-89-\ttristate \"Apple ADMAC support\"\n--\ndrivers/firmware/efi/Kconfig=154=config EFI_DEV_PATH_PARSER\n--\ndrivers/firmware/efi/Kconfig-156-\ndrivers/firmware/efi/Kconfig:157:config APPLE_PROPERTIES\ndrivers/firmware/efi/Kconfig-158-\tbool \"Apple Device Properties\"\n--\ndrivers/iio/light/Kconfig=66=config AL3320A\n--\ndrivers/iio/light/Kconfig-75-\ndrivers/iio/light/Kconfig:76:config APDS9160\ndrivers/iio/light/Kconfig-77-\ttristate \"APDS9160 combined als and proximity sensor\"\n--\ndrivers/iio/light/Kconfig-86-\ndrivers/iio/light/Kconfig:87:config APDS9300\ndrivers/iio/light/Kconfig-88-\ttristate \"APDS9300 ambient light sensor\"\n--\ndrivers/iio/light/Kconfig-96-\ndrivers/iio/light/Kconfig:97:config APDS9306\ndrivers/iio/light/Kconfig-98-\ttristate \"Avago APDS9306 Ambient Light Sensor\"\n--\ndrivers/iio/light/Kconfig-108-\ndrivers/iio/light/Kconfig:109:config APDS9960\ndrivers/iio/light/Kconfig-110-\ttristate \"Avago APDS9960 gesture/RGB/ALS/proximity sensor\"\n--\ndrivers/iommu/Kconfig=296=config SPAPR_TCE_IOMMU\n--\ndrivers/iommu/Kconfig-303-\ndrivers/iommu/Kconfig:304:config APPLE_DART\ndrivers/iommu/Kconfig-305-\ttristate \"Apple DART IOMMU Support\"\n--\ndrivers/irqchip/Kconfig=788=config IRQ_IDT3243X\n--\ndrivers/irqchip/Kconfig-792-\ndrivers/irqchip/Kconfig:793:config APPLE_AIC\ndrivers/irqchip/Kconfig-794-\tbool \"Apple Interrupt Controller (AIC)\"\n--\ndrivers/misc/Kconfig=327=config SGI_GRU_DEBUG\n--\ndrivers/misc/Kconfig-333-\ndrivers/misc/Kconfig:334:config APDS9802ALS\ndrivers/misc/Kconfig-335-\ttristate \"Medfield Avago APDS9802 ALS Sensor module\"\n--\ndrivers/net/ethernet/8390/Kconfig=106=config NE2K_PCI\n--\ndrivers/net/ethernet/8390/Kconfig-123-\ndrivers/net/ethernet/8390/Kconfig:124:config APNE\ndrivers/net/ethernet/8390/Kconfig-125-\ttristate \"PCMCIA NE2000 support\"\n--\ndrivers/net/wireless/realtek/rtw89/pci.c=3320=static int rtw89_pci_cfg_dac(struct rtw89_dev *rtwdev, bool force)\n--\ndrivers/net/wireless/realtek/rtw89/pci.c-3332-\ndrivers/net/wireless/realtek/rtw89/pci.c:3333:\t/* Configure DAC only via PCI config API, not DBI interfaces */\ndrivers/net/wireless/realtek/rtw89/pci.c-3334-\tret = pci_read_config_byte(pdev, RTW89_PCIE_L1_CTRL, \u0026val);\n--\ndrivers/perf/Kconfig=253=config MARVELL_CN10K_TAD_PMU\n--\ndrivers/perf/Kconfig-259-\ndrivers/perf/Kconfig:260:config APPLE_M1_CPU_PMU\ndrivers/perf/Kconfig-261-\tbool \"Apple M1 CPU PMU support\"\n--\ndrivers/platform/x86/Kconfig=194=config ADV_SWBUTTON\n--\ndrivers/platform/x86/Kconfig-204-\ndrivers/platform/x86/Kconfig:205:config APPLE_GMUX\ndrivers/platform/x86/Kconfig-206-\ttristate \"Apple Gmux Driver\"\n--\ndrivers/pmdomain/apple/Kconfig=3=if ARCH_APPLE || COMPILE_TEST\ndrivers/pmdomain/apple/Kconfig-4-\ndrivers/pmdomain/apple/Kconfig:5:config APPLE_PMGR_PWRSTATE\ndrivers/pmdomain/apple/Kconfig-6-\tbool \"Apple SoC PMGR power state control\"\n--\ndrivers/power/supply/Kconfig=18=config POWER_SUPPLY_HWMON\n--\ndrivers/power/supply/Kconfig-30-\ndrivers/power/supply/Kconfig:31:config APM_POWER\ndrivers/power/supply/Kconfig-32-\ttristate \"APM emulation for class batteries\"\n--\ndrivers/soc/apple/Kconfig=5=menu \"Apple SoC drivers\"\ndrivers/soc/apple/Kconfig-6-\ndrivers/soc/apple/Kconfig:7:config APPLE_MAILBOX\ndrivers/soc/apple/Kconfig-8-\ttristate \"Apple SoC mailboxes\"\n--\ndrivers/soc/apple/Kconfig-18-\ndrivers/soc/apple/Kconfig:19:config APPLE_RTKIT\ndrivers/soc/apple/Kconfig-20-\ttristate \"Apple RTKit co-processor IPC protocol\"\n--\ndrivers/soc/apple/Kconfig-30-\ndrivers/soc/apple/Kconfig:31:config APPLE_SART\ndrivers/soc/apple/Kconfig-32-\ttristate \"Apple SART DMA address filter\"\n--\ndrivers/soc/apple/Kconfig-40-\ndrivers/soc/apple/Kconfig:41:config APPLE_TUNABLE\ndrivers/soc/apple/Kconfig-42-\ttristate\n--\ndrivers/usb/misc/Kconfig=147=config USB_QCOM_EUD\n--\ndrivers/usb/misc/Kconfig-158-\ndrivers/usb/misc/Kconfig:159:config APPLE_MFI_FASTCHARGE\ndrivers/usb/misc/Kconfig-160-\ttristate \"Fast charge control for iOS devices\"\n--\ndrivers/video/Kconfig=6=menu \"Graphics support\"\ndrivers/video/Kconfig-7-\ndrivers/video/Kconfig:8:config APERTURE_HELPERS\ndrivers/video/Kconfig-9-\tbool\n--\ndrivers/watchdog/Kconfig=1111=config MSC313E_WATCHDOG\n--\ndrivers/watchdog/Kconfig-1122-\ndrivers/watchdog/Kconfig:1123:config APPLE_WATCHDOG\ndrivers/watchdog/Kconfig-1124-\ttristate \"Apple SoC watchdog\"\n--\nfs/xfs/xfs_super.c=1652=xfs_fs_fill_super(\n--\nfs/xfs/xfs_super.c-1664-\t * is guaranteed to have been completed by either the old mount API or\nfs/xfs/xfs_super.c:1665:\t * the newer fsopen/fsconfig API.\nfs/xfs/xfs_super.c-1666-\t */\n--\nkernel/power/Kconfig=310=config PM_TRACE_RTC\n--\nkernel/power/Kconfig-327-\nkernel/power/Kconfig:328:config APM_EMULATION\nkernel/power/Kconfig-329-\ttristate \"Advanced Power Management Emulation\"\n"
}

gemini-3.1-pro-preview

							input: 52508
							output: 37
							thoughts: 62

**Examining the s390 Architecture Configuration**

Okay, so I'm looking at this `CONFIG_AP` option, and my first instinct is to trace where it's defined. Right, the path is `arch/s390/Kconfig:796`. That tells me the context is the s390 architecture's configuration file. Now I'm mentally parsing the dependencies. If we're enabling `CONFIG_AP`, logically, we're likely going to need a few other elements to come along for the ride. I'm thinking immediately about `VFIO_AP`, `KVM`, and `VFIO`, and of course the base `AP` component itself.

Alright, let's just go ahead and dive into the `arch/s390/Kconfig` file and confirm my thinking. I'll search for the `AP` configuration option and see what the dependencies or implied connections are there. This should give me a clearer picture of what enabling this involves at the kernel level.

{
  "File": "arch/s390/Kconfig",
  "FirstLine": 790,
  "LineCount": 20
}

{
  "Contents": " 790:\t\t  This driver allows usage of EADM subchannels. EADM subchannels act\n 791:\t\t  as a communication vehicle for SCM increments.\n 792:\t\n 793:\t\t  To compile this driver as a module, choose M here: the\n 794:\t\t  module will be called eadm_sch.\n 795:\t\n 796:\tconfig AP\n 797:\t\tdef_tristate y\n 798:\t\tprompt \"Support for Adjunct Processors (ap)\"\n 799:\t\thelp\n 800:\t\t  This driver allows usage to Adjunct Processor (AP) devices via\n 801:\t\t  the ap bus, cards and queues. Supported Adjunct Processors are\n 802:\t\t  the CryptoExpress Cards (CEX).\n 803:\t\n 804:\t\t  To compile this driver as a module, choose M here: the\n 805:\t\t  module will be called ap.\n 806:\t\n 807:\t\t  If unsure, say Y (default).\n 808:\t\n 809:\tconfig AP_DEBUG\n"
}

gemini-3.1-pro-preview

							input: 53121
							output: 39
							thoughts: 367

**My Initial Thoughts on VFIO-AP Kernel Module Symbol Analysis**

Alright, let's break this down. `CONFIG_AP` is the foundation, Adjunct Processor support. Okay, got it. Now, what's required? The list is: `VFIO_AP`, `KVM`, `VFIO`, and `AP`. Hold on, `AP` is tristate, defaulted to 'y'. Great, that's taken care of. `VFIO_AP` is defaulted to 'n' though. So, the key is enabling `VFIO_AP`. It depends on `KVM`, `VFIO`, and `AP`, so I need to be mindful of those dependencies. `KVM` and `VFIO` are pretty standard fare though, so I'm going to focus on enabling `VFIO_AP`.

Now, for symbol analysis, I need to focus on these: `vfio_ap_mdev_set_kvm`, `vfio_ap_mdev_unset_kvm`, `vfio_ap_mdev_open_device`, `vfio_ap_mdev_close_device`, `vfio_ap_mdev_probe`, and `vfio_ap_mdev_init_dev`.

Let's see if `vfio_ap_mdev_set_kvm` is static. Yes, it is. But, wait... the prompt *prefers* non-static, non-inlined API entrypoints over internal static helper functions. Those static functions are often inlined by the compiler, and don't have distinct symbol addresses. Okay, I'll keep that in mind. `vfio_ap_mdev_open_device` is also static, but it's used as a callback in `vfio_ap_matrix_dev_ops`. So, I'll need to check `vfio_ap_ops.c` now to find the non-static functions for entry points.

{
  "Expression": "^[a-zA-Z_][a-zA-Z0-9_]* vfio_ap_mdev"
}

{
  "Output": "drivers/s390/crypto/vfio_ap_ops.c=2369=static struct mdev_driver vfio_ap_matrix_driver = {\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2381-\ndrivers/s390/crypto/vfio_ap_ops.c:2382:int vfio_ap_mdev_register(void)\ndrivers/s390/crypto/vfio_ap_ops.c-2383-{\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2404-\ndrivers/s390/crypto/vfio_ap_ops.c:2405:void vfio_ap_mdev_unregister(void)\ndrivers/s390/crypto/vfio_ap_ops.c-2406-{\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2410-\ndrivers/s390/crypto/vfio_ap_ops.c:2411:int vfio_ap_mdev_probe_queue(struct ap_device *apdev)\ndrivers/s390/crypto/vfio_ap_ops.c-2412-{\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2464-\ndrivers/s390/crypto/vfio_ap_ops.c:2465:void vfio_ap_mdev_remove_queue(struct ap_device *apdev)\ndrivers/s390/crypto/vfio_ap_ops.c-2466-{\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2527- */\ndrivers/s390/crypto/vfio_ap_ops.c:2528:int vfio_ap_mdev_resource_in_use(unsigned long *apm, unsigned long *aqm)\ndrivers/s390/crypto/vfio_ap_ops.c-2529-{\n--\ndrivers/s390/crypto/vfio_ap_private.h=143=struct vfio_ap_queue {\n--\ndrivers/s390/crypto/vfio_ap_private.h-154-\ndrivers/s390/crypto/vfio_ap_private.h:155:int vfio_ap_mdev_register(void);\ndrivers/s390/crypto/vfio_ap_private.h:156:void vfio_ap_mdev_unregister(void);\ndrivers/s390/crypto/vfio_ap_private.h-157-\ndrivers/s390/crypto/vfio_ap_private.h:158:int vfio_ap_mdev_probe_queue(struct ap_device *queue);\ndrivers/s390/crypto/vfio_ap_private.h:159:void vfio_ap_mdev_remove_queue(struct ap_device *queue);\ndrivers/s390/crypto/vfio_ap_private.h-160-\ndrivers/s390/crypto/vfio_ap_private.h:161:int vfio_ap_mdev_resource_in_use(unsigned long *apm, unsigned long *aqm);\ndrivers/s390/crypto/vfio_ap_private.h-162-\n"
}

gemini-3.1-pro-preview

							input: 54802
							output: 26
							thoughts: 525

**Identifying Key API Entry Points for Analysis**

Okay, let's break this down. My initial thought process focused on identifying the key entry points into this code, particularly the modified portions. The prompt emphasizes non-static, non-inlined API functions, which are distinct, callable units.

I started by listing the obvious non-static functions: `vfio_ap_mdev_register`, `vfio_ap_mdev_unregister`, `vfio_ap_mdev_probe_queue`, `vfio_ap_mdev_remove_queue`, and `vfio_ap_mdev_resource_in_use`. These are clearly entry points.

Then, I started to question the static ones. `vfio_ap_mdev_open_device` is a callback within `vfio_device_ops`, so even though it's static, its address is taken, ensuring it won't be fully inlined. It's essentially an entry point. The same is true for `vfio_ap_mdev_close_device`.

I considered `vfio_ap_mdev_ioctl` and `vfio_ap_mdev_probe`, but quickly dismissed them, as they were static and likely internal helpers.

I then revisited the idea of listing `vfio_ap_mdev_set_kvm` and `vfio_ap_mdev_unset_kvm` directly, as they are crucial for setting up the KVM context. Although they were static, `vfio_ap_mdev_set_kvm` is called from `vfio_ap_mdev_open_device` and is likely not fully inlined because of its size.

However, given the prompt's preference, `vfio_ap_mdev_open_device` and `vfio_ap_mdev_close_device` are the key entry points for the modified code. These are callbacks, so they are not inlined, and they are important to understand how the KVM context is set and unset.

I'll double-check to confirm that `vfio_ap_mdev_set_kvm` and `vfio_ap_mdev_unset_kvm` aren't called from anywhere else, just to be thorough.

{
  "Expression": "vfio_ap_mdev_set_kvm"
}

{
  "Output": "drivers/s390/crypto/vfio_ap_ops.c=1813=static const struct attribute_group *vfio_ap_mdev_attr_groups[] = {\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1818-/**\ndrivers/s390/crypto/vfio_ap_ops.c:1819: * vfio_ap_mdev_set_kvm - sets all data for @matrix_mdev that are needed\ndrivers/s390/crypto/vfio_ap_ops.c-1820- * to manage AP resources for the guest whose state is represented by @kvm\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1827- */\ndrivers/s390/crypto/vfio_ap_ops.c:1828:static int vfio_ap_mdev_set_kvm(struct ap_matrix_mdev *matrix_mdev,\ndrivers/s390/crypto/vfio_ap_ops.c-1829-\t\t\t\tstruct kvm *kvm)\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2048=static int vfio_ap_mdev_open_device(struct vfio_device *vdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2055-\ndrivers/s390/crypto/vfio_ap_ops.c:2056:\treturn vfio_ap_mdev_set_kvm(matrix_mdev, vdev-\u003ekvm);\ndrivers/s390/crypto/vfio_ap_ops.c-2057-}\n"
}

gemini-3.1-pro-preview

							input: 56279
							output: 26
							thoughts: 35

Okay, here's my interpretation of those thoughts, framed as an expert's internal monologue:

**Investigating the Caller Context**

Hmm, so this particular function, whatever it is, is only called from `vfio_ap_mdev_open_device`. Interesting. And, of course, from `vfio_ap_mdev_unset_kvm`. That's a limited set of callers. Knowing this is key, as it dramatically constrains the scenarios I need to consider when debugging or refactoring. This information will inform my understanding of the execution flow and potential side effects within the VFIO architecture. This also helps with understanding and debugging how the VFIO AP (Address-Space Pass-Through) functionality handles device access and KVM interactions.

{
  "Expression": "vfio_ap_mdev_unset_kvm"
}

{
  "Output": "drivers/s390/crypto/vfio_ap_ops.c=1860=static void vfio_ap_mdev_dma_unmap(struct vfio_device *vdev, u64 iova,\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1873-/**\ndrivers/s390/crypto/vfio_ap_ops.c:1874: * vfio_ap_mdev_unset_kvm - performs clean-up of resources no longer needed\ndrivers/s390/crypto/vfio_ap_ops.c-1875- * by @matrix_mdev.\n--\ndrivers/s390/crypto/vfio_ap_ops.c-1878- */\ndrivers/s390/crypto/vfio_ap_ops.c:1879:static void vfio_ap_mdev_unset_kvm(struct ap_matrix_mdev *matrix_mdev)\ndrivers/s390/crypto/vfio_ap_ops.c-1880-{\n--\ndrivers/s390/crypto/vfio_ap_ops.c=2059=static void vfio_ap_mdev_close_device(struct vfio_device *vdev)\n--\ndrivers/s390/crypto/vfio_ap_ops.c-2063-\ndrivers/s390/crypto/vfio_ap_ops.c:2064:\tvfio_ap_mdev_unset_kvm(matrix_mdev);\ndrivers/s390/crypto/vfio_ap_ops.c-2065-}\n"
}

gemini-3.1-pro-preview

							input: 56918
							output: 34
							thoughts: 190

**My Analysis of VFIO-AP Related Functions**

Alright, let me break this down. My initial focus is on the `vfio_ap_mdev_close_device` function, since that's where the initial prompt directed me. I'm going to list `vfio_ap_mdev_open_device` and `vfio_ap_mdev_close_device` as my primary FocusSymbols. I'll also include `vfio_ap_mdev_set_kvm` and `vfio_ap_mdev_unset_kvm` just to be thorough, especially if they aren't inlined anywhere.

Now, let's circle back to the configurations. I need to explicitly enable `VFIO_AP`. It looks like `KVM` and `VFIO` are baseline and assumed in most virtualization and syzkaller contexts. But hold on... `VFIO_AP` is defined as `def_tristate n`? That confirms it, I definitely need to enable it. Just to be completely sure, let me check the `drivers/s390/crypto/Makefile` file to make sure I haven't missed anything else.

{
  "Expression": "vfio_ap",
  "PathPrefix": "drivers/s390/crypto/Makefile"
}

{
  "Output": "drivers/s390/crypto/Makefile=34=obj-$(CONFIG_PKEY_UV) += pkey-uv.o\n--\ndrivers/s390/crypto/Makefile-36-# adjunct processor matrix\ndrivers/s390/crypto/Makefile:37:vfio_ap-objs := vfio_ap_drv.o vfio_ap_ops.o\ndrivers/s390/crypto/Makefile:38:obj-$(CONFIG_VFIO_AP) += vfio_ap.o\n"
}

gemini-3.1-pro-preview

							input: 57532
							output: 169
							thoughts: 434

**VFIO AP Driver Reachability in a Virtualized Environment**

Okay, so `CONFIG_VFIO_AP` is the key configuration option here, that much is clear. The question is, is this code path accessible in a standard QEMU environment? The answer, thankfully, is yes. We can leverage syzkaller to create an mdev device through sysfs, and then open the VFIO device. The beauty of the `vfio_ap` driver is that it *doesn't* actually require any physical AP hardware to get that mdev device created. We confirmed this by examining the functions `vfio_ap_mdev_probe` and `vfio_ap_matrix_dev_create`. Critically, even if `test_facility(12)` returns false (meaning no AP instructions are available on the physical host), `vfio_ap_matrix_dev_create` still succeeds. All `vfio_ap_mdev_probe` seems to do is allocate memory and register the device.

Then, when the VFIO device gets opened, `vfio_ap_mdev_open_device` is invoked. This in turn calls `vfio_ap_mdev_set_kvm`, which checks `kvm->arch.crypto.crycbd`. The crucial part here is that `crycbd` gets set when a KVM VM is created, irrespective of the presence of physical AP hardware. It just populates either `CRYCB_FORMAT1` or `CRYCB_FORMAT2`. Therefore, this entire code path is completely reachable within a virtualized setting, without needing to worry about the underlying hardware.

So, let's summarize the key takeaways:

* **WorthFuzzing: True** - Definitely worth fuzzing, this is reachable.
* **FocusSymbols:** I'm going to want to focus on:
* `vfio_ap_mdev_open_device`
* `vfio_ap_mdev_close_device`
* `vfio_ap_mdev_set_kvm`
* `vfio_ap_mdev_unset_kvm`
* **EnableConfigs:** Clearly, just `VFIO_AP` is needed.

The reasoning is solid: The patch affects locking and state management in the VFIO AP driver when attaching and detaching mediated devices from KVM guests. Since the driver can be loaded, mdevs can be created and opened in a virtual environment via sysfs and VFIO ioctls, making this a prime candidate for fuzzing.

the following configs do not exist in the kernel tree: VFIO_AP

{
  "EnableConfigs": [
    "VFIO_AP"
  ],
  "FocusSymbols": [
    "vfio_ap_mdev_open_device",
    "vfio_ap_mdev_close_device",
    "vfio_ap_mdev_set_kvm",
    "vfio_ap_mdev_unset_kvm"
  ],
  "Reasoning": "The patch modifies locking semantics and state management in the VFIO AP driver when a mediated device is attached to or detached from a KVM guest. The vfio_ap driver can be loaded and mdevs can be created and opened in a virtualized environment without requiring physical AP hardware, making this code reachable and fuzzable via sysfs and VFIO ioctls.",
  "WorthFuzzing": true
}

{
  "error": "the following configs do not exist in the kernel tree: VFIO_AP"
}

gemini-3.1-pro-preview

							input: 58717
							output: 19
							thoughts: 30

Here's my thought process, as if I were considering this issue:

**Investigating a Missing Configuration Option**

Okay, hold on a second. I was under the impression that `VFIO_AP` was a valid configuration option for s390, but something's not adding up. I'm getting a feeling that I'm chasing a phantom here. Let's not assume, though, and jump to conclusions.

The best approach is to double-check the source of truth for these s390 configuration options. I need to go back to the `arch/s390/Kconfig` file and confirm, definitively, whether or not `VFIO_AP` is actually defined there. This is a critical first step. I can't build my analysis on a false premise. I'll need to meticulously scan through that Kconfig to be absolutely sure. Then I can proceed with further debugging, based on the actual Kconfig reality.

{
  "Expression": "config VFIO_AP"
}

{
  "Output": "arch/s390/Kconfig=823=config VFIO_CCW\n--\narch/s390/Kconfig-833-\narch/s390/Kconfig:834:config VFIO_AP\narch/s390/Kconfig-835-\tdef_tristate n\n"
}

gemini-3.1-pro-preview

							input: 59061
							output: 169
							thoughts: 241

**VFIO_AP Conundrum**

Okay, so I'm seeing that the `VFIO_AP` option is, in fact, defined within `arch/s390/Kconfig`. That's a bit perplexing because the `set-results` tool just told me it doesn't exist. Hmm, I bet the tool is checking against, say, an x86_64-based configuration. That would make sense, as these tools can sometimes be overly generalized. The error message is clear: "the following configs do not exist in the kernel tree: VFIO_AP".

Right, I need to verify that there isn't a typo or some other obvious mistake on my part. Yep, I confirm the path is correct: `arch/s390/Kconfig` *definitely* has `config VFIO_AP`. This makes me think the tool might be looking at a default defconfig, or perhaps comparing against a particular architecture other than the one I'm working with.

I'm tempted to just resubmit it, but wait, I know the tool rejected it. Should I omit it altogether, or just provide it and ignore the error?

Ah, I remember the prompt. It says to use the tool, then ignore the results. "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." So I can simply call it again and disregard the failure?

But, wait a second... if it failed, did the tool actually *save* the results, the first time I called it? I need to check. Okay, I'll call it again just to be sure.

the following configs do not exist in the kernel tree: VFIO_AP

{
  "EnableConfigs": [
    "VFIO_AP"
  ],
  "FocusSymbols": [
    "vfio_ap_mdev_open_device",
    "vfio_ap_mdev_close_device",
    "vfio_ap_mdev_set_kvm",
    "vfio_ap_mdev_unset_kvm"
  ],
  "Reasoning": "The patch modifies locking semantics and state management in the VFIO AP driver when a mediated device is attached to or detached from a KVM guest. The vfio_ap driver can be loaded and mdevs can be created and opened in a virtualized environment without requiring physical AP hardware, making this code reachable and fuzzable via sysfs and VFIO ioctls.",
  "WorthFuzzing": true
}

{
  "error": "the following configs do not exist in the kernel tree: VFIO_AP"
}

gemini-3.1-pro-preview

							input: 59858
							output: 335
							thoughts: 50

**My Immediate Response to the Situation**

Okay, the instructions are clear: disregard any errors from the previous tool. No need to get bogged down in details that the prompt explicitly tells me to bypass. I understand my task and I'm moving forward. I'm operating on the assumption that `VFIO_AP` is indeed defined within `arch/s390/Kconfig`. This seems like a reasonable assumption based on my prior knowledge and experience. Now, with this confirmed, I'll proceed directly to deliver the requested final response, as planned. There's no need for further investigation or verification at this point.

gemini-3.1-pro-preview

							input: 55516
							output: 193
							thoughts: 356

**Troubleshooting Configuration Discrepancy**

Okay, so `set-results` just crapped out with a "configs do not exist" error, specifically mentioning `VFIO_AP`. This is puzzling. Why isn't it seeing the configuration? My first thought is, am I mistakenly thinking this is an x86-specific thing? Does the tool make assumptions about the architecture and check configs only against x86_64? I need to verify. The tool *should* be checking against the kernel tree, and `VFIO_AP` *is* in `arch/s390/Kconfig`.

If the tool is using a script internally, maybe it is only designed to check against x86 configurations. I need to make sure I'm not missing something in the `arch/s390/Kconfig`. Ah yes, `VFIO_AP` is definitely defined in `arch/s390/Kconfig`.

If the tool isn't recognizing it, perhaps I should just omit it entirely, providing only `KVM` and `VFIO`. Let me just be absolutely sure... Wait, the tool's error message *explicitly* says `VFIO_AP` doesn't exist. Now that I think about it, should I be using `CONFIG_VFIO_AP` instead? Actually, I could just omit the config altogether if it's not recognized. Maybe I should just try `AP`?

Okay, let me check the relevant `Makefile`. Let's see... looking at `drivers/s390/crypto/Makefile`... `obj-$(CONFIG_VFIO_AP) += vfio_ap.o`. So, it *is* `VFIO_AP`. It's definitely the correct configuration.

So, why the heck is the tool saying it doesn't exist? Maybe I need to look at the tool's supported config types to make sure it can handle `VFIO_AP`. Maybe it's just defaulting to x86_64?

Alright, the best course of action here is to simply omit `VFIO_AP` from `EnableConfigs` and explain this discrepancy in the `Reasoning` section. Or, on second thought, maybe I can just provide an empty list for `EnableConfigs` and explain the situation.

{
  "EnableConfigs": [],
  "FocusSymbols": [
    "vfio_ap_mdev_open_device",
    "vfio_ap_mdev_close_device",
    "vfio_ap_mdev_set_kvm",
    "vfio_ap_mdev_unset_kvm"
  ],
  "Reasoning": "The patch modifies locking semantics and state management in the VFIO AP driver when a mediated device is attached to or detached from a KVM guest. The vfio_ap driver can be loaded and mdevs can be created and opened in a virtualized environment without requiring physical AP hardware, making this code reachable and fuzzable via sysfs and VFIO ioctls. (Note: VFIO_AP config is required but omitted from EnableConfigs as it is s390x specific and rejected by the tool).",
  "WorthFuzzing": true
}

{
  "EnableConfigs": null,
  "FocusSymbols": [
    "vfio_ap_mdev_open_device",
    "vfio_ap_mdev_close_device",
    "vfio_ap_mdev_set_kvm",
    "vfio_ap_mdev_unset_kvm"
  ],
  "Reasoning": "The patch modifies locking semantics and state management in the VFIO AP driver when a mediated device is attached to or detached from a KVM guest. The vfio_ap driver can be loaded and mdevs can be created and opened in a virtualized environment without requiring physical AP hardware, making this code reachable and fuzzable via sysfs and VFIO ioctls. (Note: VFIO_AP config is required but omitted from EnableConfigs as it is s390x specific and rejected by the tool).",
  "WorthFuzzing": true
}

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

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