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

On Sun, Dec 06, 2015 at 09:46:56PM -0500, Cole Robinson wrote: > Hi all, [...] > Here are some possible solutions: > > * Drop the current behavior of adding a PCIe controller unconditionally, and > instead require apps to specify it in the XML. Then, if libvirt sees a PCIe > controller in the XML, default the virtio address type to pci. Apps will know > if the OS they are installing supports virtio-pci (eventually via libosinfo), > so this is the way we can implicitly ask libvirt 'allocate us pci addresses' For now this is probably better solution considering the fact that there is minimal support from OSes. But eventually it would be better to switch to PCIe as default. From libvirt POV we should allow to choose between mmio and PCIe to override the default. This would resolve the current situation and also the future state, where PCIe will became the preferred one. > > Upsides: > - Solves both the stated problems. > - Simplest addition for applications IMO > > Downsides: > - Requires a libvirt behavior change, no longer adding the PCIe controller by > default. But in practice I don't think it will really affect anyone, since > there isn't really any OS support for virtio-pci yet, and no apps support it > either AFAIK. > - The PCIe controller is not strictly about virtio-pci, it's for enabling > plain emulated PCI devices as well. So there is a use case for using the PCIe > controller for a graphics card even while your OS doesn't yet support > virtio-pci. In the big picture though this is a small time window with current > OS, and users can work around it by manually requesting <address > type='virtio-mmio'/>, so medium/long term this isn't a big deal IMO > - The PCIe controller XML is: > <controller type='pci' index='0' model='pcie-root'/> > <controller type='pci' index='1' model='dmi-to-pci-bridge'/> > <controller type='pci' index='2' model='pci-bridge'/> > I have no idea if that's always going to be the expected XML, maybe it's not > wise to hardcode that in apps. Laine? No, hardcoded staff tend to be short-term solution and makes more pain in the future to get rid of them and don't break anything. The other thing is, aarch64 doesn't have i82801b11-bridge controller, which is used for dmi-to-pci-bridge. I'm not even sure, whether pci-bridge is required for aarch64 to use pci devices.

> > > * Next idea: Users specify something like like <address type='pci'/> and > libvirt fills in the address for us. This would be nice feature to specify address type and let libvirt fill remaining address information and add required controllers or report that required controllers are missing.