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.
Pavel
[...]