Re: [PATCH v4 1/4] vpci: Use pervcpu ranges for BAR mapping

["Roger Pau Monné" <roger.pau@citrix.com>]

On Thu, Apr 16, 2026 at 05:29:26PM +0200, Jan Beulich wrote:
> On 06.04.2026 21:11, Stewart Hildebrand wrote:
> > From: Mykyta Poturai <Mykyta_Poturai@epam.com>
> > 
> > There is no need to store ranges for each PCI device, as they are only
> > used during the mapping/unmapping process and can be reused for each
> > device. This also allows to avoid the need to allocate and destroy
> > rangesets for each device.
> > 
> > Move the rangesets from struct vpci_bar to struct vpci_vcpu and perform
> > (de-)allocation with vcpu (de-)allocation. Introduce RANGESET_DESTROY()
> > macro to free a rangeset and set the pointer to NULL.
> > 
> > Amends: 622bdd962822 ("vpci/header: handle p2m range sets per BAR")
> > Signed-off-by: Mykyta Poturai <mykyta_poturai@epam.com>
> > Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
> > ---
> > It seems a bit awkward to introduce various vpci vcpu alloc/dealloc
> > functions here only to undo most of it in the next patch. Thoughts on
> > folding the next patch into this one?
> > 
> > v3->v4:
> > * no change
> 
> There are some complexities here due to the patch being part of two series.
> Once Mykyta re-submits the SR-IOV series, we'll have two (likely diverging)
> v4-s. Already here ...
> 
> > v2->v3:
> > * new patch in this series, borrowed from [1]
> > * add Amends tag
> > * remove unused variable i due to rebasing over 998060dd9101 ("vPCI:
> >   move vpci_init_capabilities() to a separate file")
> > * enclose entire struct vpci_vcpu inside #ifdef __XEN__
> > * s/bar_mem/mem/
> > * use ARRAY_SIZE
> > * put init/destroy in functions
> > * only allocate for domains with vPCI and idle domain
> > * replace 'if ( !mem ) continue;' with ASSERT
> 
> ... the v3 there has one more item on this ChangeLog list ("* synced with
> BAR write with memory decoding enabled series[1]"), albeit maybe (now that I
> read it again) this merely is the counterpart of the first bullet point here.
> It would be clearer if there the other series' title was supplied verbatim
> and in quotes.

Indeed.  I reviewed the one from Mykyta part of the SR-IOV series.
I see both Jan and myself made similar comments, I'm also a bit
concerned about the claim that moving to per-vCPU ranges is better
than using per-pdev ranges, see the comments on the SR-IOV series.

Overall however it seems to me for the SR-IOV series we will need to
allocate mapping tasks on demand, so we will neither have per-vCPU or
per-pdev per-allocated tasks (that include the rangeset).  I think we
need a pre-series that introduce the map queueing plus the on-demand
allocation of tasks in a clean way (iow: there's no need to introduce
per-vCPU tasks if they need to be replaced with runtime allocation
tasks for the SR-IOV support).

Then both this series and the SR-IOV one should be rebased over that
work.

Thanks, Roger.