On 12/07/2015 06:38 AM, Pavel Hrdina wrote: > 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. > Yeah maybe we can add a convenience options like <controller type='pcie'/> that libvirt converts to the correct topology for qemu. Dunno. Step 1 is figuring out if that XML even makes sense for qemu aarch64 >> >> >> * 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. > Yeah I'll look into it. - Cole -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list