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

[Cole Robinson]

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