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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20250822081258.27bc71da.alex.williamson@redhat.com>
Date: Fri, 22 Aug 2025 08:12:58 -0600
From: Alex Williamson <alex.williamson@...hat.com>
To: Shameer Kolothum <shameerkolothum@...il.com>
Cc: liulongfang <liulongfang@...wei.com>, 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 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,

Alex