> >> > diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c index > >> > 6a4e38856d..74683e7445 100644 > >> > --- a/hw/pci/pci_bridge.c > >> > +++ b/hw/pci/pci_bridge.c > >> > @@ -380,6 +380,7 @@ void pci_bridge_initfn(PCIDevice *dev, const char > >> *typename) > >> > sec_bus->map_irq = br->map_irq ? br->map_irq : > >> pci_swizzle_map_irq_fn; > >> > sec_bus->address_space_mem = &br->address_space_mem; > >> > memory_region_init(&br->address_space_mem, OBJECT(br), > >> > "pci_bridge_pci", UINT64_MAX); > >> > + address_space_init(&br->as_mem, &br->address_space_mem, > >> > + "pci_bridge_pci"); > >> > >> I don't think this "pci_bridge_pci" address space is necessary. The > >> VirtIOPCIProxy.modern_as AddressSpace is sufficient for > >> memory_region_add() to work. > > > > This is because memory_region_find_rcu () and > > memory_region_to_address_space() will find the memory container > > on the top level and then get the corresponding address space of it. > > If we only add "VirtIOPCIProxy.modern_as AddressSpace", > > memory_region_find() still cannot find a address space. > > Because "pci_bridge_pci" is the memory container on top level and it > > doesn't have a corresponding address space. > > > Got your point. That address space can help when a so-ill-behaved guest > enables both the bridge and the virtio device, clears the memory base of > secondary bus and then accesses the virtio configurations via the PCI > config access cap. Thanks for the clarification. > > > As mentioned earlier, you may want to add the I/O space counterparts for > both address spaces, as the cap can target modern I/O BARs (when they > are present) as well.
Thanks, I'll add a address space for I/O BARs in the next version.
