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