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
>
> .
>
prev parent 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®