On Sat, 2014-10-25 at 14:24 +0200, Jan Kiszka wrote: > On 2014-10-25 13:36, Jan Kiszka wrote: > > On 2014-10-21 00:34, Knut Omang wrote: > >> diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c > >> index 40c97b1..e6832c4 100644 > >> --- a/hw/pci/pci_bridge.c > >> +++ b/hw/pci/pci_bridge.c > >> @@ -376,8 +376,14 @@ int pci_bridge_initfn(PCIDevice *dev, const char > >> *typename) > >> sec_bus->address_space_io = &br->address_space_io; > >> memory_region_init(&br->address_space_io, OBJECT(br), > >> "pci_bridge_io", 65536); > >> br->windows = pci_bridge_region_init(br); > >> + > >> QLIST_INIT(&sec_bus->child); > >> QLIST_INSERT_HEAD(&parent->child, sec_bus, sibling); > >> + > >> + if (dev->bus->iommu_opaque) { > >> + pci_setup_iommu(sec_bus, dev->bus->iommu_fn, > >> dev->bus->iommu_opaque); > >> + } > >> + > > > > So, if I followed the discussion in the cover-letter thread correctly, > > this should rather move into the bridge device init functions because > > the PCI[e]-PCI bridge ("pci-bridge") would not call it, right? > > Not right. We need the setup in any case (except for the virtio bridges > I'm currently thinking of for encapsulating non-translatable virtio > devices). But something still has to change to reflect the requester ID > aliasing of the PCIe-PCI bridge, no?
Yes, that's my understanding too. Knut