AI Trajectory

null

{
  "EnableConfigs": [
    "MICROSOFT_MANA",
    "PCI_HYPERV"
  ],
  "FocusSymbols": [
    "mana_sriov_configure",
    "mana_gd_remove"
  ],
  "Reasoning": "The patch adds SR-IOV configuration support to the MANA driver and modifies the remove function to disable SR-IOV. These are functional changes to the PCI driver that can be reached via sysfs and PCI device removal.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit bfcf01cad23b2644ddd6ebaed05a454cf8d1a65b\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Sat Jul 11 16:55:50 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c\nindex aef3b77229c131..a38d4bb74621f9 100644\n--- a/drivers/net/ethernet/microsoft/mana/gdma_main.c\n+++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c\n@@ -2456,6 +2456,8 @@ static void mana_gd_remove(struct pci_dev *pdev)\n {\n \tstruct gdma_context *gc = pci_get_drvdata(pdev);\n \n+\tpci_disable_sriov(pdev);\n+\n \tmana_rdma_remove(\u0026gc-\u003emana_ib);\n \tmana_remove(\u0026gc-\u003emana, false);\n \n@@ -2525,6 +2527,27 @@ static void mana_gd_shutdown(struct pci_dev *pdev)\n \tpci_disable_device(pdev);\n }\n \n+static int mana_sriov_configure(struct pci_dev *pdev, int numvfs)\n+{\n+\tint err = 0;\n+\n+\tdev_info(\u0026pdev-\u003edev, \"Requested num VFs: %d\\n\", numvfs);\n+\n+\tif (numvfs \u003e 0) {\n+\t\terr = pci_enable_sriov(pdev, numvfs);\n+\t} else {\n+\t\tif (pci_vfs_assigned(pdev)) {\n+\t\t\tdev_warn(\u0026pdev-\u003edev,\n+\t\t\t\t \"Cannot disable SR-IOV while VFs are assigned\\n\");\n+\t\t\treturn -EPERM;\n+\t\t}\n+\n+\t\tpci_disable_sriov(pdev);\n+\t}\n+\n+\treturn err ? err : numvfs;\n+}\n+\n static const struct pci_device_id mana_id_table[] = {\n \t{ PCI_DEVICE(PCI_VENDOR_ID_MICROSOFT, MANA_PF_DEVICE_ID) },\n \t{ PCI_DEVICE(PCI_VENDOR_ID_MICROSOFT, MANA_PF2_DEVICE_ID) },\n@@ -2540,6 +2563,7 @@ static struct pci_driver mana_driver = {\n \t.suspend\t= mana_gd_suspend,\n \t.resume\t\t= mana_gd_resume,\n \t.shutdown\t= mana_gd_shutdown,\n+\t.sriov_configure = mana_sriov_configure,\n };\n \n static int __init mana_driver_init(void)\n"
}

gemini-3.1-pro-preview

null

{
  "EnableConfigs": [
    "MICROSOFT_MANA",
    "PCI_HYPERV"
  ],
  "FocusSymbols": [
    "mana_sriov_configure",
    "mana_gd_remove"
  ],
  "Reasoning": "The patch adds SR-IOV configuration support to the MANA driver and modifies the remove function to disable SR-IOV. These are functional changes to the PCI driver that can be reached via sysfs and PCI device removal.",
  "WorthFuzzing": true
}

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

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

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

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

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Do not list too generic configs (we already have them enabled). Only list those that
   specifically cover the modified code. List them in the EnableConfigs output array,
   and DO NOT add a 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

For your convenience, here is the diff of the changes:
commit bfcf01cad23b2644ddd6ebaed05a454cf8d1a65b
Author: syz-cluster <triage@syzkaller.com>
Date:   Sat Jul 11 16:55:50 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c
index aef3b77229c131..a38d4bb74621f9 100644
--- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
+++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c
@@ -2456,6 +2456,8 @@ static void mana_gd_remove(struct pci_dev *pdev)
 {
 	struct gdma_context *gc = pci_get_drvdata(pdev);
 
+	pci_disable_sriov(pdev);
+
 	mana_rdma_remove(&gc->mana_ib);
 	mana_remove(&gc->mana, false);
 
@@ -2525,6 +2527,27 @@ static void mana_gd_shutdown(struct pci_dev *pdev)
 	pci_disable_device(pdev);
 }
 
+static int mana_sriov_configure(struct pci_dev *pdev, int numvfs)
+{
+	int err = 0;
+
+	dev_info(&pdev->dev, "Requested num VFs: %d\n", numvfs);
+
+	if (numvfs > 0) {
+		err = pci_enable_sriov(pdev, numvfs);
+	} else {
+		if (pci_vfs_assigned(pdev)) {
+			dev_warn(&pdev->dev,
+				 "Cannot disable SR-IOV while VFs are assigned\n");
+			return -EPERM;
+		}
+
+		pci_disable_sriov(pdev);
+	}
+
+	return err ? err : numvfs;
+}
+
 static const struct pci_device_id mana_id_table[] = {
 	{ PCI_DEVICE(PCI_VENDOR_ID_MICROSOFT, MANA_PF_DEVICE_ID) },
 	{ PCI_DEVICE(PCI_VENDOR_ID_MICROSOFT, MANA_PF2_DEVICE_ID) },
@@ -2540,6 +2563,7 @@ static struct pci_driver mana_driver = {
 	.suspend	= mana_gd_suspend,
 	.resume		= mana_gd_resume,
 	.shutdown	= mana_gd_shutdown,
+	.sriov_configure = mana_sriov_configure,
 };
 
 static int __init mana_driver_init(void)

gemini-3.1-pro-preview

null

null

							input: 2281
							output: 37
							thoughts: 257
						

**Analyzing the MANA Driver Patch for Reachability and Fuzzing Potential**

Okay, so I'm looking at this patch that tweaks the `gdma_main.c` file for the MANA driver. It adds `mana_sriov_configure` to the `mana_driver` structure as the `.sriov_configure` function pointer, and importantly, it calls `pci_disable_sriov(pdev)` in `mana_gd_remove`. My immediate thought is, can this code path *actually* be triggered in a virtualized environment? This is a Microsoft Azure Network Adapter driver, so it's probably pretty specific.

Can QEMU even *emulate* this hardware directly? My instinct is no. MANA is, from what I understand, tightly coupled with the Azure infrastructure. Fuzzing this driver effectively is the next thing I'm considering. Hardware-specific drivers like this are often a dead end for standard fuzzing unless there's an emulator.

However, I'm trying to think more broadly. Can syzkaller reach this? I know syzkaller *can* fuzz PCI devices, especially if you can inject the devices via `syz_pci_device` or similar. But that usually needs specific and potentially tricky setup, right? Ah, but wait, I remember syzkaller *does* have a PCI fuzzer, vhci/pci, if I'm remembering that correctly. I should investigate that further.

Alright, let's also quickly check the Kconfig. I want to see if there's any conditional compilation involved. Let's look in `drivers/net/ethernet/microsoft/Kconfig`. Time to grep for "MANA" and see what dependencies or build options might exist. That might give me some clues about how easily this driver can be activated and potentially fuzzable.

{
  "Expression": "config MICROSOFT_MANA",
  "PathPrefix": "drivers/net/ethernet/microsoft/Kconfig"
}

{
  "Output": "drivers/net/ethernet/microsoft/Kconfig=16=if NET_VENDOR_MICROSOFT\ndrivers/net/ethernet/microsoft/Kconfig-17-\ndrivers/net/ethernet/microsoft/Kconfig:18:config MICROSOFT_MANA\ndrivers/net/ethernet/microsoft/Kconfig-19-\ttristate \"Microsoft Azure Network Adapter (MANA) support\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 3075
							output: 33
							thoughts: 15
						

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

**Analyzing Dependencies for `MICROSOFT_MANA`**

Okay, let's dive in. I need to understand the architectural footprint of `MICROSOFT_MANA`. My immediate concern is its dependencies. Knowing what components or services `MICROSOFT_MANA` relies upon is crucial for a variety of tasks, from impact analysis and troubleshooting to planning for updates or migrations. I need a clear dependency graph, either explicitly documented or, ideally, something I can infer through analysis. I'm thinking about things like:

*   Does it rely on any core infrastructure components? (like message queues, specific database versions, caching layers, etc.)
*   Are there external API calls? And if so, how robust are those dependencies?
*   Any in-house libraries or shared code that are critical to its operation?
*   What's the transitive dependency tree? I need to understand the full scope, not just direct dependencies.

The answers to these questions will inform everything else I do with `MICROSOFT_MANA` today.

{
  "Expression": "depends on",
  "PathPrefix": "drivers/net/ethernet/microsoft/Kconfig"
}

{
  "Output": "drivers/net/ethernet/microsoft/Kconfig=18=config MICROSOFT_MANA\ndrivers/net/ethernet/microsoft/Kconfig-19-\ttristate \"Microsoft Azure Network Adapter (MANA) support\"\ndrivers/net/ethernet/microsoft/Kconfig:20:\tdepends on PCI_MSI\ndrivers/net/ethernet/microsoft/Kconfig:21:\tdepends on X86_64 || (ARM64 \u0026\u0026 !CPU_BIG_ENDIAN)\ndrivers/net/ethernet/microsoft/Kconfig:22:\tdepends on PCI_HYPERV\ndrivers/net/ethernet/microsoft/Kconfig-23-\tselect AUXILIARY_BUS\n"
}

gemini-3.1-pro-preview

null

null

							input: 3531
							output: 38
							thoughts: 841
						

**SR-IOV Configuration Fuzzing Assessment**

Okay, so I'm looking at this patch and my initial thought is, "does this warrant fuzzing?" It hinges on `PCI_HYPERV`, which immediately makes me think of Hyper-V, and then, can syzkaller even reach it? The core of the change is the addition of `.sriov_configure`, hooked up via sysfs for SR-IOV configuration on a PCI device. Syzkaller *can* fuzz sysfs, so that's a positive.

The `mana_sriov_configure` function itself, the key function, is calling standard `pci_enable_sriov` and `pci_disable_sriov` calls. It is quite a boilerplate-like function, but specific to the MANA hardware. I'd want to check if there's *any* other logic hidden in there, but I don't see anything.

```c
static int mana_sriov_configure(struct pci_dev *pdev, int numvfs)
{
	int err = 0;

	dev_info(&pdev->dev, "Requested num VFs: %d\n", numvfs);

	if (numvfs > 0) {
		err = pci_enable_sriov(pdev, numvfs);
	} else {
		if (pci_vfs_assigned(pdev)) {
			dev_warn(&pdev->dev,
				 "Cannot disable SR-IOV while VFs are assigned\n");
			return -EPERM;
		}

		pci_disable_sriov(pdev);
	}

	return err ? err : numvfs;
}
```

This is pretty straightforward, but the MANA dependency on `PCI_HYPERV` is the key. Syzkaller generally doesn't target Hyper-V specific hardware unless it's running in that environment, and even then, this function is fairly small. Still, is it worth the effort? I need to think about my instructions here - should this be fuzzed?

I remember the instructions on WorthFuzzing: no if the change is documentation, Kconfig, comments, logging, constants, or unreachable code paths. This is a functional change, but MANA's reachability is questionable.

But wait! Can MANA reach QEMU? Syzkaller can emulate PCI devices, but needs the device to probe. This depends on `PCI_HYPERV`, and QEMU *does* support Hyper-V enlightenments and VMBus. I can see QEMU and syzkaller working together for this.

Syzkaller can emulate PCI devices by matching vendor/device IDs. The vendor ID is `PCI_VENDOR_ID_MICROSOFT` (0x1414) and the device ID is `MANA_PF_DEVICE_ID` (0x00ba). If syzkaller provides these values, the MANA driver should probe! This is good. It's reachable.

Therefore, `mana_sriov_configure` is a functional change. I'll need to focus on it, plus `mana_gd_remove`. And the enable configurations will be `MICROSOFT_MANA`, and `PCI_HYPERV`.

I should probably double-check that `MICROSOFT_MANA` is the *right* config. Yes, it is!
`config MICROSOFT_MANA`.

I also should double check any other config.

{
  "Expression": "mana_sriov_configure",
  "PathPrefix": "drivers/net/ethernet/microsoft/mana/"
}

{
  "Output": "drivers/net/ethernet/microsoft/mana/gdma_main.c=2516=static void mana_gd_shutdown(struct pci_dev *pdev)\n--\ndrivers/net/ethernet/microsoft/mana/gdma_main.c-2529-\ndrivers/net/ethernet/microsoft/mana/gdma_main.c:2530:static int mana_sriov_configure(struct pci_dev *pdev, int numvfs)\ndrivers/net/ethernet/microsoft/mana/gdma_main.c-2531-{\n--\ndrivers/net/ethernet/microsoft/mana/gdma_main.c=2558=static struct pci_driver mana_driver = {\n--\ndrivers/net/ethernet/microsoft/mana/gdma_main.c-2565-\t.shutdown\t= mana_gd_shutdown,\ndrivers/net/ethernet/microsoft/mana/gdma_main.c:2566:\t.sriov_configure = mana_sriov_configure,\ndrivers/net/ethernet/microsoft/mana/gdma_main.c-2567-};\n"
}

gemini-3.1-pro-preview

null

null

							input: 5473
							output: 33
							thoughts: 126
						

**Configuring the Mana SRIOV Functionality**

Okay, so I see they've added the `mana_sriov_configure` function; good, good. Now, let's see what needs to be enabled. Ah, `MICROSOFT_MANA`. That makes sense. But wait a minute... is `PCI_HYPERV` also needed? Yes, of course, it's a dependency. Typically, we'd just list the direct config, `MICROSOFT_MANA`, but let's play it safe this time and include *both*.

Hold on… `PCI_HYPERV` itself depends on `X86_64` and `HYPERV`. Right, that makes sense with the platform dependencies, especially if we're working in a hypervisor environment. Just to be absolutely sure I'm not missing anything, let me cross-reference the `PCI_HYPERV` config in the `drivers/pci/controller/Kconfig` file. Always good to double-check these dependencies.

{
  "Expression": "config PCI_HYPERV",
  "PathPrefix": "drivers/pci/controller/"
}

{
  "Output": "drivers/pci/controller/Kconfig=235=config PCIE_MT7621\n--\ndrivers/pci/controller/Kconfig-242-\ndrivers/pci/controller/Kconfig:243:config PCI_HYPERV_INTERFACE\ndrivers/pci/controller/Kconfig-244-\ttristate \"Microsoft Hyper-V PCI Interface\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 5956
							output: 26
							thoughts: 28
						

Okay, here's my take on those thoughts, tailored for an expert audience:

**PCI_HYPERV Location Inquiry**

Hmm, so I'm just double-checking something here, and I'm a bit surprised. *PCI_HYPERV*... that seems to indicate something related to the PCI interface in a Hyper-V environment, right? I was mentally associating it with the broader PCI subsystem, perhaps even the general Hyper-V drivers. Now I'm taking a moment to confirm, and the codebase reference is confirming my understanding. It is located at `drivers/pci/controller/pci-hyperv.c`. Right, that makes perfect sense. This specific controller driver implementation will be handling the interaction between the Hyper-V environment and the emulated/virtualized PCI devices. Got it.

{
  "Expression": "config PCI_HYPERV",
  "PathPrefix": ""
}

{
  "Output": "drivers/pci/Kconfig=229=config PCI_LABEL\n--\ndrivers/pci/Kconfig-232-\ndrivers/pci/Kconfig:233:config PCI_HYPERV\ndrivers/pci/Kconfig-234-\ttristate \"Hyper-V PCI Frontend\"\n--\ndrivers/pci/controller/Kconfig=235=config PCIE_MT7621\n--\ndrivers/pci/controller/Kconfig-242-\ndrivers/pci/controller/Kconfig:243:config PCI_HYPERV_INTERFACE\ndrivers/pci/controller/Kconfig-244-\ttristate \"Microsoft Hyper-V PCI Interface\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 6362
							output: 29
							thoughts: 21
						

Here's my take on those thoughts, tailored for an expert audience:

**Investigating the PCI_HYPERV Configuration**

Okay, so I need to understand the configuration options related to PCI Hyper-V support within the kernel. My first instinct, given my experience, is to head directly to the `drivers/pci/Kconfig` file. That's the canonical location for PCI-related configuration options in the kernel, and `Kconfig` files are where all the magic happens when configuring the build system. I'm expecting to find the definition for `PCI_HYPERV` in there. Hopefully, the commentary within the `Kconfig` file is thorough enough to give me the information I need about dependencies, potential conflicts, and the purpose of enabling this functionality. Knowing the dependencies will be key; does it require specific hypervisor support, certain hardware features, or other kernel modules to be enabled? I’ll also be looking for any hints about the underlying PCI devices that are targeted by this option.

{
  "Expression": "depends on",
  "PathPrefix": "drivers/pci/Kconfig"
}

{
  "Output": "drivers/pci/Kconfig=21=menuconfig PCI\ndrivers/pci/Kconfig-22-\tbool \"PCI support\"\ndrivers/pci/Kconfig:23:\tdepends on HAVE_PCI\ndrivers/pci/Kconfig:24:\tdepends on MMU\ndrivers/pci/Kconfig-25-\thelp\n--\ndrivers/pci/Kconfig=70=config PCI_DEBUG\ndrivers/pci/Kconfig-71-\tbool \"PCI Debugging\"\ndrivers/pci/Kconfig:72:\tdepends on DEBUG_KERNEL\ndrivers/pci/Kconfig-73-\thelp\n--\ndrivers/pci/Kconfig=80=config PCI_REALLOC_ENABLE_AUTO\ndrivers/pci/Kconfig-81-\tbool \"Enable PCI resource re-allocation detection\"\ndrivers/pci/Kconfig:82:\tdepends on PCI_IOV\ndrivers/pci/Kconfig-83-\thelp\n--\ndrivers/pci/Kconfig=100=config PCI_PF_STUB\ndrivers/pci/Kconfig-101-\ttristate \"PCI PF Stub driver\"\ndrivers/pci/Kconfig:102:\tdepends on PCI_IOV\ndrivers/pci/Kconfig-103-\thelp\n--\ndrivers/pci/Kconfig=111=config XEN_PCIDEV_FRONTEND\ndrivers/pci/Kconfig-112-\ttristate \"Xen PCI Frontend\"\ndrivers/pci/Kconfig:113:\tdepends on XEN_PV\ndrivers/pci/Kconfig-114-\tselect PCI_XEN\n--\ndrivers/pci/Kconfig=167=config PCI_NPEM\ndrivers/pci/Kconfig-168-\tbool \"Native PCIe Enclosure Management\"\ndrivers/pci/Kconfig:169:\tdepends on LEDS_CLASS=y\ndrivers/pci/Kconfig-170-\thelp\n--\ndrivers/pci/Kconfig=206=config PCI_P2PDMA\ndrivers/pci/Kconfig-207-\tbool \"PCI peer-to-peer transfer support\"\ndrivers/pci/Kconfig:208:\tdepends on ZONE_DEVICE\ndrivers/pci/Kconfig-209-\t#\n--\ndrivers/pci/Kconfig-212-\t#\ndrivers/pci/Kconfig:213:\tdepends on 64BIT\ndrivers/pci/Kconfig-214-\tselect GENERIC_ALLOCATOR\n--\ndrivers/pci/Kconfig=233=config PCI_HYPERV\ndrivers/pci/Kconfig-234-\ttristate \"Hyper-V PCI Frontend\"\ndrivers/pci/Kconfig:235:\tdepends on ((X86 \u0026\u0026 X86_64) || ARM64) \u0026\u0026 HYPERV_VMBUS \u0026\u0026 PCI_MSI \u0026\u0026 SYSFS\ndrivers/pci/Kconfig-236-\tselect PCI_HYPERV_INTERFACE\n--\ndrivers/pci/Kconfig=242=config PCI_DYNAMIC_OF_NODES\ndrivers/pci/Kconfig-243-\tbool \"Create Device tree nodes for PCI devices\"\ndrivers/pci/Kconfig:244:\tdepends on OF_IRQ\ndrivers/pci/Kconfig-245-\tselect OF_DYNAMIC\n--\ndrivers/pci/Kconfig=254=config VGA_ARB\n--\ndrivers/pci/Kconfig-256-\tdefault y\ndrivers/pci/Kconfig:257:\tdepends on !S390\ndrivers/pci/Kconfig-258-\tselect SCREEN_INFO if X86\n--\ndrivers/pci/Kconfig=266=config VGA_ARB_MAX_GPUS\n--\ndrivers/pci/Kconfig-268-\tdefault 16\ndrivers/pci/Kconfig:269:\tdepends on VGA_ARB\ndrivers/pci/Kconfig-270-\thelp\n"
}

gemini-3.1-pro-preview

null

null

							input: 7608
							output: 109
							thoughts: 537
						

**My Analysis of the MANA Driver and Syzkaller Fuzzing Potential**

Okay, let's break this down. My initial thought was that since the `MANA` device is a PCI device and not directly a VMBus device, it might not be immediately reachable by Syzkaller's existing VMBus fuzzing capabilities. I was right to think that `PCI_HYPERV` depends on `HYPERV_VMBUS`, and that Syzkaller *can* fuzz Hyper-V VMBus devices if the VMBus component is enabled.

But then I realized something crucial. `PCI_HYPERV` isn't *just* about VMBus in isolation. It's the Hyper-V PCI Frontend. That means it presents PCI devices to the guest system *through* the VMBus. This is the key.

My first concern was that the lack of a specific VMBus fuzzer in syzkaller could be a blocker. However, after a quick check, I see there are already some VMBus descriptions in `sys/linux/dev_vmbus.txt`. It gives me some hope.

However, the real breakthrough is realizing that the `MANA` driver itself is a standard PCI driver, registering as a `pci_driver`. This is great news. The Syzkaller PCI fuzzer can interact with this device directly via the PCI subsystem. It can inject the device directly, bypassing the VMBus entirely, and the PCI subsystem will just see a PCI device with matching vendor/device IDs and probe it appropriately. That means the device is definitely reachable and this is an excellent opportunity for fuzzing.

My conclusion is that `MANA` is worth fuzzing. I'll focus on the `mana_sriov_configure` and `mana_gd_remove` functions, given their likely impact. I will enable the configs `MICROSOFT_MANA` and `PCI_HYPERV`. Now that I see `mana_gd_remove` has been modified to include `pci_disable_sriov(pdev);` I am even more convinced.

{
  "EnableConfigs": [
    "MICROSOFT_MANA",
    "PCI_HYPERV"
  ],
  "FocusSymbols": [
    "mana_sriov_configure",
    "mana_gd_remove"
  ],
  "Reasoning": "The patch adds SR-IOV configuration support to the MANA driver and modifies the remove function to disable SR-IOV. These are functional changes to the PCI driver that can be reached via sysfs and PCI device removal.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "MICROSOFT_MANA",
    "PCI_HYPERV"
  ],
  "FocusSymbols": [
    "mana_sriov_configure",
    "mana_gd_remove"
  ],
  "Reasoning": "The patch adds SR-IOV configuration support to the MANA driver and modifies the remove function to disable SR-IOV. These are functional changes to the PCI driver that can be reached via sysfs and PCI device removal.",
  "WorthFuzzing": true
}