On Tue, 2017-06-13 at 22:10 -0400, Laine Stump wrote: > > Usually, a controller with alias 'x' will create a bus with the > > same name; however, the bus created by a PHBs with alias 'x' will > > be named 'x.0' instead, so we need to account for that. > > This doesn't make sense to me. My recollection (without going through > the code again) is that for PCI controllers, the alias for pci-root is > "pci.0" as long as the qemu binary supports multiple PCI controllers > (otherwise it is just "pci"), and the alias is pcie.0 for pcie-root, > then all other PCI controllers have the alias (i.e. value of "contAlias" > in this function) of pci.x (where "x" is the index of the controller). That's correct. > What you're saying here doesn't match that. Unless you're saying that > the PHBs will have aliases named something like "pci.1.0" (which isn't > what I see in the test cases in 19/26). So here's the subtle bit: for all PCI controllers *except* spapr-pci-host-brigde, the bus name for a controller will match the controller alias, so you'll have -device pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0x1 -device virtio-scsi-pci,id=scsi0,bus=pci.1,addr=0x1 spapr-pci-host-bridge will behave slightly differently, in that a controller with alias x will create a bus with name x.0, so you'll have to use -device spapr-pci-host-bridge,index=1,id=pci.1 -device virtio-scsi-pci,id=scsi0,bus=pci.1.0,addr=0x1 instead. To add to the fun, the implicit PHB (despite being an instance of the same device) will create a bus named pci.0 just like you'd expect. Hence this patch :) You can see this in action in patch 22/26; later patches will also move more devices to separate PHBs, so by the end of the series there will be a bunch of test cases covering this behavior. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list