Re: [libvirt] How should libvirt apps enable virtio-pci for aarch64?

On 12/07/2015 10:37 AM, Cole Robinson wrote: That was only intended for the Q35 machinetype (but somehow all of them got turned on by a patch to add pcie-root to aarch64 virt machinetypes). pcie-root is included in the hardware by qemu on Q35, and can't be removed. dmi-to-pci-bridge translates from the PCIe ports of pcie-root to standard pci ports (but non-hotpluggable), and pci-bridge converts from non-hotpluggable PCI to hotpluggable PCI, which is the kind of slots that management applications expect to be available. Other machinetypes don't need to do this same thing (for that matter, in the future this may not be the most desirable way to go for Q35 - in the 2 (or is it 3) years since Q35 support was added, I've learned that pretty much every emulated PCI device in qemu can be plugged into a PCIe port (on the Q35 machinetype at least) with no complaints from qemu, and we now have pcie-root-port and pcie-switch-downstream-port (with matching pcie-switch-upstream-port) that can accept hotplugged devices, so a Q35 machine could now be constructed as: <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-root-port'/> <controller type='pci' index='2' model='pcie-switch-upstream-port'/> <controller type='pci' index='3' model='pcie-switch-downstream-port'/> <controller type='pci' index='4' model='pcie-switch-downstream-port'/> ... and the address assignment could be modified to allow auto-selection of PCIe ports for PCI devices (the downstream ports support hotplugging devices, but can't be hotplugged themselves, and they can only be plugged into an upstream port, which can only be plugged into a root-port (or a downstream-port)). At any rate, I don't think the current PCIe bus structure should be hardcoded anywhere. We can change what libvirt does by default any time; existing configs will continue with what we setup in the past (and thus won't suffer "your hardware has changed! Reactivate!!" problems), but newly created ones will use whatever new model we come up with. This is very possible. ADDRESS_TYPE_PCI means that the PCI address is "valid". 0000:00:00.0 is a valid PCI address (although it happens to be reserved on any x86 architecture. For the bit early on after the parse we may need to have a separate "valid address" flag beyond the type to prevent confusion. I do like the idea of being able to say "<address type='pci'/> to select the bus without specifying an address though. I *kind of* agree with this, but not completely. I think that if we know for sure based on introspection of the virtual machine (or based on verified knowledge that we hardcode into libvirt) that there is a PCI controller of some type that is implemented in the machine and no way to remove it, we should put that information in the XML. Any controllers that are optional, and don't exist in the virtual machine if they're not added to the commandline, can be auto-added only if needed. So for example, if a Q35 domain was created that had just 2 emulated PCI devices, we could auto-add just enough ports to accommodate that. (For that matter, adding an emulated PCI device would cause the auto-add of a pcie-switch-downstream-port, which might cause the auto-add of a pcie-switch-upstream-port, which might cause the auto-add of a pcie-root-port; the 2nd emulated PCI device would cause an auto-add of another pcie-switch-downstream-port which would find a spot in the existing pcie-switch-upstream-port) The one problem with doing this would be that there would be no free ports for hotplugging; I'm not sure what is the best way to deal with that; I suppose any attempt at hotplugging a new device would lead to an error, after which you would shut down the virtual machine, manually add in a port, then start it up again; or maybe when there are *any* PCI devices, we could always make sure there were 'several' extra ports for hotplugging? Neither sounds ideal...).