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

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

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.

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