From: Alex Williamson <alex.williamson@redhat.com>
To: Shameer Kolothum <shameerkolothum@gmail.com>
Cc: liulongfang <liulongfang@huawei.com>,
jgg@nvidia.com, jonathan.cameron@huawei.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, linuxarm@openeuler.org
Subject: Re: [PATCH v8 3/3] hisi_acc_vfio_pci: adapt to new migration configuration
Date: Fri, 22 Aug 2025 08:12:58 -0600 [thread overview]
Message-ID: <20250822081258.27bc71da.alex.williamson@redhat.com> (raw)
In-Reply-To: <723cd569-b194-4876-9aea-d0bdd6861810@gmail.com>
On Fri, 22 Aug 2025 08:03:39 +0100
Shameer Kolothum <shameerkolothum@gmail.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@huawei.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
next prev parent reply other threads:[~2025-08-22 14:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-20 7:24 [PATCH v8 0/3] update live migration configuration region Longfang Liu
2025-08-20 7:24 ` [PATCH v8 1/3] hisi_acc_vfio_pci: update BAR space size Longfang Liu
2025-08-20 7:24 ` [PATCH v8 2/3] crypto: hisilicon - qm updates BAR configuration Longfang Liu
2025-08-20 7:24 ` [PATCH v8 3/3] hisi_acc_vfio_pci: adapt to new migration configuration Longfang Liu
2025-08-21 18:01 ` Alex Williamson
2025-08-22 2:44 ` liulongfang
2025-08-22 7:03 ` Shameer Kolothum
2025-08-22 14:12 ` Alex Williamson [this message]
2025-08-30 9:13 ` liulongfang
2025-08-30 9:08 ` liulongfang
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=20250822081258.27bc71da.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=jgg@nvidia.com \
--cc=jonathan.cameron@huawei.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@openeuler.org \
--cc=liulongfang@huawei.com \
--cc=shameerkolothum@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).