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

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

[Ariadne Conill]

From: Steven Noonan <steven@edera.dev>

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.

Signed-off-by: Steven Noonan <steven@edera.dev>
Signed-off-by: Ariadne Conill <ariadne@ariadne.space>
---
 xen/drivers/vpci/header.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index 739a5f610e..852dfd8ae3 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -1011,7 +1011,7 @@ int vpci_init_header(struct pci_dev *pdev)
         }
 
         bars[i].addr = addr;
-        bars[i].guest_addr = addr;
+        bars[i].guest_addr = is_hwdom ? addr : 0;
         bars[i].size = size;
         bars[i].prefetchable = val & PCI_BASE_ADDRESS_MEM_PREFETCH;
 
@@ -1034,7 +1034,7 @@ int vpci_init_header(struct pci_dev *pdev)
         rom->type = VPCI_BAR_ROM;
         rom->size = size;
         rom->addr = addr;
-        rom->guest_addr = addr;
+        rom->guest_addr = is_hwdom ? addr : 0;
         header->rom_enabled = pci_conf_read32(pdev->sbdf, rom_reg) &
                               PCI_ROM_ADDRESS_ENABLE;
 
-- 
2.53.0

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

[Jan Beulich]

On 25.02.2026 00:12, Ariadne Conill wrote:
> From: Steven Noonan <steven@edera.dev>
> 
> 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?

Jan

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

[Stewart Hildebrand]

On 2/25/26 10:37, Jan Beulich wrote:
> On 25.02.2026 00:12, Ariadne Conill wrote:
>> From: Steven Noonan <steven@edera.dev>
>>
>> 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.

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

[Jan Beulich]

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@edera.dev>
>>>
>>> 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.

Jan

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

[Roger Pau Monné]

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@edera.dev>
> >>>
> >>> 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.