Re: [libvirt] [PATCH 17/26] qemu: Deal with PHB naming convention
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