Re: [PATCH] xen/vpci: zero guest-visible BAR addresses to ensure domU asssigns its own

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Feb 26, 2026 at 08:47:52AM +0100, Jan Beulich wrote:
> On 26.02.2026 03:50, Stewart Hildebrand wrote:
> > On 2/25/26 10:37, Jan Beulich wrote:
> >> On 25.02.2026 00:12, Ariadne Conill wrote:
> >>> From: Steven Noonan <steven@xxxxxxxxx>
> >>>
> >>> If we just use the host's BAR addresses, the domU might not attempt to
> >>> reconfigure the BAR ranges and may never try to map them with the IOMMU.
> >>> Zeroing them ensures the guest kernel knows the BARs are not configured
> >>> and needs to make its own choices about where to map the BARs.
> >>
> >> Yet for this, don't we first need to expose a full topology to the guest,
> >> i.e. at least a host bridge, and maybe further bridges?
> > While we eventually do want to expose (a) virtual bridge(s) to vPCI domUs 
> > (this
> > work is currently in development), I don't think it's pre-requisite for the 
> > code
> > change herein: clearly, leaking host BAR addresses to domUs isn't right, and
> > there's no need to wait to address that.
> > 
> > With that said, the commit title/description don't align well with the code
> > change. Assuming we want to move the code change forward, for v2 of the 
> > patch I
> > suggest dropping the 2nd half of the title, and reworking the commit 
> > description
> > to focus on describing the code change at hand and less on what the domU 
> > might
> > do.
> 
> That would indeed work for me.

+1.  The "try to map them with the IOMMU" wording is not accurate
IMO, and wants replacing.

It would also be nice to mention that zeroing unconditionally is fine,
because for domUs the memory decoding bit is also unconditionally
cleared, so there will be no attempt to map the BARs into the guest
p2m by vpci_init_header().

Thanks, Roger.