linux-kernel - Re: [PATCH v8 3/3] hisi_acc_vfio_pci: adapt to new migration configuration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6f383882-b358-b578-faa9-8312289e61ee@huawei.com>
Date: Sat, 30 Aug 2025 17:13:07 +0800
From: liulongfang <liulongfang@...wei.com>
To: Alex Williamson <alex.williamson@...hat.com>, Shameer Kolothum
	<shameerkolothum@...il.com>
CC: <jgg@...dia.com>, <jonathan.cameron@...wei.com>, <kvm@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linuxarm@...neuler.org>
Subject: Re: [PATCH v8 3/3] hisi_acc_vfio_pci: adapt to new migration
 configuration

On 2025/8/22 22:12, Alex Williamson wrote:
> On Fri, 22 Aug 2025 08:03:39 +0100
> Shameer Kolothum <shameerkolothum@...il.com> wrote:
> 
>> On 22/08/2025 03:44, liulongfang wrote:
>>> On 2025/8/22 2:01, Alex Williamson wrote:  
>>>> On Wed, 20 Aug 2025 15:24:35 +0800
>>>> Longfang Liu <liulongfang@...wei.com> wrote:
>>>>> +enum hw_drv_mode {
>>>>> +	HW_V3_COMPAT = 0,
>>>>> +	HW_V4_NEW,
>>>>> +};  
>>>>
>>>> You might consider whether these names are going to make sense in the
>>>> future if there a V5 and beyond, and why V3 hardware is going to use a
>>>> "compat" name when that's it's native operating mode.
>>>>  
>>>
>>> If future versions such as V5 or higher emerge, we can still handle them by
>>> simply updating the version number.
>>> The use of "compat" naming is intended to ensure that newer hardware versions
>>> remain compatible with older drivers.
>>> For simplicity, we could alternatively rename them directly to HW_ACC_V3, HW_ACC_V4,
>>> HW_ACC_V5, etc.
>>>   
>>>> But also, patch 1/ is deciding whether to expose the full BAR based on
>>>> the hardware version and here we choose whether to use the VF or PF
>>>> control registers based on the hardware version and whether the new
>>>> hardware feature is enabled.  Doesn't that leave V4 hardware exposing
>>>> the full BAR regardless of whether the PF driver has disabled the
>>>> migration registers within the BAR?  Thanks,
>>>>  
>>>
>>> Regarding V4 hardware: the migration registers within the PF's BAR are
>>> accessible only by the host driver, just like other registers in the BAR.
>>> When the VF's live migration configuration registers are enabled, the driver
>>> can see the full BAR configuration space of the PF.However, at this point,
>>> the PF's live migration configuration registers become read/write ineffective.
>>> In other words, on V4 hardware, the VF's configuration domain and the PF's
>>> configuration domain are mutually exclusive—only one of them is ever read/write
>>> valid at any given time.  
>>
>> Sorry it is still not clear to me. My understanding was on V4 hardware,
>> the VF's live migration config register will be inactive only when you
>> set the PF's QM_MIG_REGION_SEL to QM_MIG_REGION_EN.
>>
>> So, I think the question is whether you need to check the PF's
>> QM_MIG_REGION_SEL has set to  QM_MIG_REGION_EN, in patch 1 before
>> exposing the full VF BAR region or not. If yes, you need to reorganise
>> the patch 1. Currently patch 1 only checks the hardware version to
>> decide that.
> 
> This, and also is there any migration compatibility between V3 hardware
> and V4 hardware in compat mode?  Changing the BAR size is a fundamental
> hardware difference that would preclude that unless something like QEMU
> masks the true BAR size to the guest.  Thanks,
>

This difference will not affect migration compatibility. For our device migration,
we only need to ensure that the device can be restored correctly after migration.
Although the BAR size may differ depending on the device configuration, the data
required to restore the device and ensure its normal operation remains consistent.

Thanks.
Longfang.


> Alex
> 
> 
> .
>