mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: liulongfang <liulongfang@huawei.com>
To: Alex Williamson <alex@shazbot.org>
Cc: <alex.williamson@redhat.com>, <jgg@nvidia.com>,
	<kvm@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 3/3] hisi_acc_vfio_pci: reject live migration on 64KB page with QM_HW_V3 hardware
Date: Thu, 17 Sep 2026 14:13:23 +0800	[thread overview]
Message-ID: <ecb52830-2900-a018-67f0-24b4829e722b@huawei.com> (raw)
In-Reply-To: <20260911113721.35d7383d@shazbot.org>

On 2026/9/12 1:37, Alex Williamson wrote:
> On Mon, 31 Aug 2026 17:09:51 +0800
> Longfang Liu <liulongfang@huawei.com> wrote:
> 
>> 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 4abed2e49986..4f12cab96545 100644
>> --- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
>> +++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
>> @@ -1210,6 +1210,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;
>> +		}
>> +	}
>> +
> 
> Sashiko correctly identifies that this breaks any assignment on 64K
> pages, which is contradictory to the comment that indicates this is
> only intended to disable migration support.  This should instead be
> invoking the non-migration path in the probe function.  Thanks,
>

It is a reasonable approach to directly select the non-migration ops in the probe
function based on the logic check.
I plan to implement this in the next revision and complete testing and verification.

Thanks.
Longfang.

> Alex
> 
> .
> 

      reply	other threads:[~2026-09-17  6:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31  9:09 [PATCH v3 0/3] hisi_acc_vfio_pci: fix three driver issues Longfang Liu
2026-08-31  9:09 ` [PATCH v3 1/3] hisi_acc_vfio_pci: fix live migration enable conditions for PF passthrough Longfang Liu
2026-09-11 17:37   ` Alex Williamson
2026-09-17  6:13     ` liulongfang
2026-09-18  3:10       ` Alex Williamson
2026-09-18  8:39         ` liulongfang
2026-08-31  9:09 ` [PATCH v3 2/3] hisi_acc_vfio_pci: clear set_reset_flag after reset completed Longfang Liu
2026-08-31  9:09 ` [PATCH v3 3/3] hisi_acc_vfio_pci: reject live migration on 64KB page with QM_HW_V3 hardware Longfang Liu
2026-09-11 17:37   ` Alex Williamson
2026-09-17  6:13     ` liulongfang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ecb52830-2900-a018-67f0-24b4829e722b@huawei.com \
    --to=liulongfang@huawei.com \
    --cc=alex.williamson@redhat.com \
    --cc=alex@shazbot.org \
    --cc=jgg@nvidia.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®