Hi Michael, Alex, This patch represents a compromise I hope will be acceptable after the long thread discussing handling of multiple PCI host bridges on the pseries machine. Patch 1/1 is just a preliminary enforcing uniqueness of LIOBNs in the IOMMU code.
Patch 2/2 is the meat. It allows either explicit configuration of all the properties, or the user can just set an abstract index which will generate sensible and probably-unique values for all the rest. With these patches I was able to do something like: qemu-system-ppc64 -M pseries -m 1024 -nographic \ fc17-root.qcow2 -net none -device nec-usb-xhci -device \ spapr-pci-host-bridge,index=1 -device e1000,netdev=fred \ -netdev user,id=fred I was able to see both the PCI domains in the guest, and use the NIC on the secondary domain. There are still some gotches with multiple domains though. The domain value in PCIHostBus is still always initialized to 0, and there are other places in the PCI core where handling of multiple domains is essentially stubbed out. Michael, any thoughts on what to do about that? I could fix up the PCI code so that domain is actually set and used. But I think the whole notion of domain numbers is kind of bogus on the qemu side: since PCI domains are completely independent from each other, it's only platform convention which determines what the domain numbers are. On platforms that don't have a strong convention, the guest will number them itself and we have no way of knowing that. So it seems to me that the PCI code should instead of domain numbers just use the device ID, or the bus name or some qemu side symbolic name. For platforms that do have a numbering convention those names can be derived from the domain numbers, but it also works for platforms that don't.