[PATCH v2 0/2] hisi_acc_vfio_pci: fix two driver issues

[PATCH v2 0/2] hisi_acc_vfio_pci: fix two driver issues

[Longfang Liu]

This series of patches fixes two issues discovered in specific scenarios
within the driver: one caused by PF device passthrough, and the other
triggered by a mismatch between hardware version and memory page
size (QM_HW_V3 + 64KB pages).

Longfang Liu (2):
  hisi_acc_vfio_pci: fix live migration enable conditions for PF
    passthrough
  hisi_acc_vfio_pci: reject live migration on 64KB page with QM_HW_V3
    hardware

 .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c    | 41 ++++++++++++++++---
 1 file changed, 35 insertions(+), 6 deletions(-)

-- 
2.43.0

[PATCH v2 1/2] hisi_acc_vfio_pci: fix live migration enable conditions for PF passthrough

[Longfang Liu]

When a PF device is bound to the live migration driver in passthrough mode,
it cannot support live migration functionality, and key pointers will
remain uninitialized. Although most migration functions within the driver
are unreachable, low-level error handling callbacks may be triggered
directly, causing a crash due to null pointer dereference.
The fix involves adding validity checks at three entry points: device
probe, error handling, and migration initialization. If the pointer is
invalid, the operation is exited or rejected directly to avoid crashes,
while redundant internal checks are removed.

Fixes: b0eed085903e ("hisi_acc_vfio_pci: Add support for VFIO live migration")
Signed-off-by: Longfang Liu <liulongfang@huawei.com>
---
 .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c    | 24 ++++++++++++++-----
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
index 86362ec424a5..e95d0ab0f11a 100644
--- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
+++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
@@ -1154,9 +1154,14 @@ static void hisi_acc_vf_pci_reset_prepare(struct pci_dev *pdev)
 {
 	struct hisi_acc_vf_core_device *hisi_acc_vdev = hisi_acc_drvdata(pdev);
 	struct hisi_qm *qm = hisi_acc_vdev->pf_qm;
-	struct device *dev = &qm->pdev->dev;
+	struct device *dev = &pdev->dev;
 	u32 delay = 0;
 
+	if (!qm || !qm->io_base) {
+		dev_err(dev, "PF QM not available for reset\n");
+		return;
+	}
+
 	/* All reset requests need to be queued for processing */
 	while (test_and_set_bit(QM_RESETTING, &qm->misc_ctl)) {
 		msleep(1);
@@ -1174,8 +1179,12 @@ static void hisi_acc_vf_pci_aer_reset_done(struct pci_dev *pdev)
 	struct hisi_acc_vf_core_device *hisi_acc_vdev = hisi_acc_drvdata(pdev);
 	struct hisi_qm *qm = hisi_acc_vdev->pf_qm;
 
-	if (hisi_acc_vdev->set_reset_flag)
-		clear_bit(QM_RESETTING, &qm->misc_ctl);
+	if (hisi_acc_vdev->set_reset_flag) {
+		if (qm && qm->io_base)
+			clear_bit(QM_RESETTING, &qm->misc_ctl);
+		else
+			dev_err(&pdev->dev, "PF QM not available for reset done\n");
+	}
 
 	if (!hisi_acc_vdev->core_device.vdev.mig_ops)
 		return;
@@ -1565,6 +1574,11 @@ static int hisi_acc_vfio_pci_migrn_init_dev(struct vfio_device *core_vdev)
 	struct pci_dev *pdev = to_pci_dev(core_vdev->dev);
 	struct hisi_qm *pf_qm = hisi_acc_get_pf_qm(pdev);
 
+	if (!pf_qm) {
+		dev_err(&pdev->dev, "PF driver not loaded, cannot enable migration\n");
+		return -ENODEV;
+	}
+
 	hisi_acc_vdev->vf_id = pci_iov_vf_id(pdev) + 1;
 	hisi_acc_vdev->pf_qm = pf_qm;
 	hisi_acc_vdev->vf_dev = pdev;
@@ -1670,13 +1684,11 @@ static int hisi_acc_vfio_pci_probe(struct pci_dev *pdev, const struct pci_device
 	struct hisi_acc_vf_core_device *hisi_acc_vdev;
 	const struct vfio_device_ops *ops = &hisi_acc_vfio_pci_ops;
 	struct hisi_qm *pf_qm;
-	int vf_id;
 	int ret;
 
 	pf_qm = hisi_acc_get_pf_qm(pdev);
 	if (pf_qm && pf_qm->ver >= QM_HW_V3) {
-		vf_id = pci_iov_vf_id(pdev);
-		if (vf_id >= 0)
+		if (pdev->is_virtfn)
 			ops = &hisi_acc_vfio_pci_migrn_ops;
 		else
 			pci_warn(pdev, "migration support failed, continue with generic interface\n");
-- 
2.43.0

[PATCH v2 2/2] hisi_acc_vfio_pci: reject live migration on 64KB page with QM_HW_V3 hardware

[Longfang Liu]

In the scenario combining QM_HW_V3 hardware with 64KB large pages, the
device functional region and migration registers share the BAR2 physical
page, resulting in a lack of isolation that triggers security issues.
More critically, since KVM does not support the specific 16-byte read/write
instructions used by the guest driver, operating under the KVM emulated
device scheme will lead to Guest kernel calltrace issues.
To prevent Guest exceptions and avoid security vulnerabilities, the
driver directly disables live migration functionality in this scenario.
This ensures the system fails cleanly with an error early during startup,
while other configuration modes remain unaffected and can still utilize
passthrough functionality normally.

Fixes: b0eed085903e ("hisi_acc_vfio_pci: Add support for VFIO live migration")
Signed-off-by: Longfang Liu <liulongfang@huawei.com>
---
 drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
index e95d0ab0f11a..4e845474fa90 100644
--- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
+++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
@@ -1208,6 +1208,23 @@ static int hisi_acc_vf_qm_init(struct hisi_acc_vf_core_device *hisi_acc_vdev)
 	else
 		hisi_acc_vdev->drv_mode = HW_ACC_MIG_VF_CTRL;
 
+	/*
+	 * On VF_CTRL hardware, BAR2 holds 32KB functional + 32KB
+	 * migration registers. When the host page exceeds 32KB, the
+	 * two share one physical page and cannot be isolated by mmap.
+	 * Reject the open so QEMU fails cleanly at startup.
+	 */
+	if (hisi_acc_vdev->drv_mode == HW_ACC_MIG_VF_CTRL) {
+		resource_size_t func_len =
+			pci_resource_len(vf_dev, VFIO_PCI_BAR2_REGION_INDEX) >> 1;
+
+		if (func_len < PAGE_SIZE) {
+			dev_err(&vf_dev->dev,
+				"migration not supported on 64KB pages with QM_HW_V3\n");
+			return -EINVAL;
+		}
+	}
+
 	if (hisi_acc_vdev->drv_mode == HW_ACC_MIG_PF_CTRL) {
 		/*
 		 * On hardware platforms greater than QM_HW_V3, the migration function
-- 
2.43.0

Re: [PATCH v2 1/2] hisi_acc_vfio_pci: fix live migration enable conditions for PF passthrough

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The `set_reset_flag` lock tracker is never reset to false after a successful lock acquisition, allowing subsequent failed resets to erroneously clear the global `QM_RESETTING` lock.
--

--- Patch [1]: [PATCH v2 1/2] hisi_acc_vfio_pci: fix live migration enable conditions for PF passthrough ---
commit e8e63b8a17edd44cc9b69e8ca3472ee6c656873c
Author: Longfang Liu <liulongfang@huawei.com>

hisi_acc_vfio_pci: fix live migration enable conditions for PF passthrough

This commit fixes a crash in PF passthrough mode by adding validity
checks for uninitialized PF pointers during device probe, error
handling, and migration initialization.

> diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
> index 86362ec424a50..e95d0ab0f11ab 100644
> --- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
> +++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
[ ... ]
> @@ -1174,8 +1179,12 @@ static void hisi_acc_vf_pci_aer_reset_done(struct pci_dev *pdev)
>  	struct hisi_acc_vf_core_device *hisi_acc_vdev = hisi_acc_drvdata(pdev);
>  	struct hisi_qm *qm = hisi_acc_vdev->pf_qm;
>  
> -	if (hisi_acc_vdev->set_reset_flag)
> -		clear_bit(QM_RESETTING, &qm->misc_ctl);
> +	if (hisi_acc_vdev->set_reset_flag) {
> +		if (qm && qm->io_base)
> +			clear_bit(QM_RESETTING, &qm->misc_ctl);

[Severity: High]
This isn't a bug introduced by this patch, but is it possible that
hisi_acc_vdev->set_reset_flag is never reset to false after a successful
lock acquisition?

If a prior reset succeeds, hisi_acc_vdev->set_reset_flag is left as true.

If a subsequent reset attempt times out in hisi_acc_vf_pci_reset_prepare()
because another agent already holds the QM_RESETTING lock:

hisi_acc_vf_pci_reset_prepare() {
    ...
    while (test_and_set_bit(QM_RESETTING, &qm->misc_ctl)) {
        msleep(1);
        if (++delay > QM_RESET_WAIT_TIMEOUT) {
            dev_err(dev, "reset prepare failed\n");
            return;
        }
    }
    ...
}

The code returns early and leaves set_reset_flag as true.

When hisi_acc_vf_pci_aer_reset_done() is subsequently invoked by the PCI
error recovery flow, it observes the stale true flag and unconditionally
clears QM_RESETTING.

Does this prematurely clear the lock currently owned by the other agent?

> +		else
> +			dev_err(&pdev->dev, "PF QM not available for reset done\n");
> +	}
>  
>  	if (!hisi_acc_vdev->core_device.vdev.mig_ops)
>  		return;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260824082851.1436129-1-liulongfang@huawei.com?part=1

Re: [PATCH v2 1/2] hisi_acc_vfio_pci: fix live migration enable conditions for PF passthrough

[liulongfang]

On 2026/8/24 16:42, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] The `set_reset_flag` lock tracker is never reset to false after a successful lock acquisition, allowing subsequent failed resets to erroneously clear the global `QM_RESETTING` lock.
> --
> 
> --- Patch [1]: [PATCH v2 1/2] hisi_acc_vfio_pci: fix live migration enable conditions for PF passthrough ---
> commit e8e63b8a17edd44cc9b69e8ca3472ee6c656873c
> Author: Longfang Liu <liulongfang@huawei.com>
> 
> hisi_acc_vfio_pci: fix live migration enable conditions for PF passthrough
> 
> This commit fixes a crash in PF passthrough mode by adding validity
> checks for uninitialized PF pointers during device probe, error
> handling, and migration initialization.
> 
>> diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
>> index 86362ec424a50..e95d0ab0f11ab 100644
>> --- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
>> +++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
> [ ... ]
>> @@ -1174,8 +1179,12 @@ static void hisi_acc_vf_pci_aer_reset_done(struct pci_dev *pdev)
>>  	struct hisi_acc_vf_core_device *hisi_acc_vdev = hisi_acc_drvdata(pdev);
>>  	struct hisi_qm *qm = hisi_acc_vdev->pf_qm;
>>  
>> -	if (hisi_acc_vdev->set_reset_flag)
>> -		clear_bit(QM_RESETTING, &qm->misc_ctl);
>> +	if (hisi_acc_vdev->set_reset_flag) {
>> +		if (qm && qm->io_base)
>> +			clear_bit(QM_RESETTING, &qm->misc_ctl);
> 
> [Severity: High]
> This isn't a bug introduced by this patch, but is it possible that
> hisi_acc_vdev->set_reset_flag is never reset to false after a successful
> lock acquisition?
> 
> If a prior reset succeeds, hisi_acc_vdev->set_reset_flag is left as true.
> 
> If a subsequent reset attempt times out in hisi_acc_vf_pci_reset_prepare()
> because another agent already holds the QM_RESETTING lock:
> 
> hisi_acc_vf_pci_reset_prepare() {
>     ...
>     while (test_and_set_bit(QM_RESETTING, &qm->misc_ctl)) {
>         msleep(1);
>         if (++delay > QM_RESET_WAIT_TIMEOUT) {
>             dev_err(dev, "reset prepare failed\n");
>             return;
>         }
>     }
>     ...
> }
> 
Your analysis makes sense. After `reset_done`, if subsequent reset processing occurs,
`set_reset_flag` remains set to true. Therefore, the reset flag handling will be
executed regardless of whether `reset_prepare` succeeds or not,
which is unreasonable.

Thanks.
Longfang.

> The code returns early and leaves set_reset_flag as true.
> 
> When hisi_acc_vf_pci_aer_reset_done() is subsequently invoked by the PCI
> error recovery flow, it observes the stale true flag and unconditionally
> clears QM_RESETTING.
> 
> Does this prematurely clear the lock currently owned by the other agent?
> 
>> +		else
>> +			dev_err(&pdev->dev, "PF QM not available for reset done\n");
>> +	}
>>  
>>  	if (!hisi_acc_vdev->core_device.vdev.mig_ops)
>>  		return;
>