On Fri, 22 Aug 2025 08:03:39 +0100
Shameer Kolothum <shameerkolothum@xxxxxxxxx> 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@xxxxxxxxxx> 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
