[libvirt] [PATCH 2/2] HACK: qemu: aarch64: Use virtio-pci if user specifies PCI controller

[Cole Robinson]

On 03/10/2016 08:40 AM, Daniel P. Berrange wrote:
> On Thu, Mar 10, 2016 at 02:34:02PM +0100, Andrea Bolognani wrote:
>> On Thu, 2016-03-10 at 09:56 +0000, Daniel P. Berrange wrote:
>>> So, I've just seen that QEMU has decided that as of QEMU 2.6, the virt
>>> machine type will start to be versioned.  This is quite convenient I
>>> think as it gives us a nice thing to hook on. ie we see a non-versioned
>>> machine type of 'virt' then we use virtio-mmio addressing, however, if
>>> we see a versioned virt-X.Y.Z machine type, then we can assume pci by
>>> default.
>>>
>>> Since the long term plan for AArch64 is to use PCI for everything, this
>>> gives us nice default behaviour from this point onwards, while not
>>> breaking compatibility for existing early adopters.
>>>
>>> Of course people with "legacy" mmio-only guests will stll have a little
>>> pain to run then on new QEMU, but honestly I think that's worth it since
>>> it will avoid us long term pain in the world where aarch64 uses pci for
>>> everything
>>
>> I think it's way too early to flip the switch and default to
>> PCI addresses: my understanding is that guest OS support is
>> expected to be spotty at best for at least a couple more
>> years.
> 
> I don't buy that. For a start the only virtio-mmio and/or pci devices we
> are giving to guests are virtio devices (blk, net, balloon, etc). The
> only current guests supporting these devices are Linux, and Linux has
> support for PCI on aarch64. So any Linux distro that ships today is
> going to support PCI. Other guests (*BSD) which may choose to support
> aarch64 in future would likely go straight to PCI and not bother with
> virtio-mmio. Likewise if we did ever get a Windows guest on aarch64
> with win-virtio drivers I would expec them to be PCI based.
> 
> So AFAICT, the only distros which are going to be using virtio-mmio are
> the Linux aarch64 early-access/tech-preview releases. I don't really see
> them as an important target.  Even if we switch to PCI by default, I'd
> still expect virt-manager to be capable of being told to override the
> default and assign mmio addresses instad.
> 

It's not that simple. The kernel supports the devices fine, but there's other
bits in the chain. For example Fedora 23 + AAVMF does not work with
virtio-pci... I don't understand the specifics but it's likely to do with
as-yet-not-fully-upstreamed aarch64 ACPI support that we have in RHELSA. I
don't think any released distro works out of the box with AAVMF + virtio-pci.
CCing Drew who maybe can shed more light on specifics

That said, maybe the simpler thing is to do what you suggest: default to
virtio-pci for versioned virt-*, then teach tools to force <address
type='virtio-mmio'/> via the XML until we know distros can support it.

Means some difficult transition time for the tools in the short to medium
term, since for example an older virt-manager (which doesn't explicitly
specify virtio-mmio) will generate an incorrect XML config for Fedora 23 with
a new libvirt (which defaults to virtio-pci). But maybe it's just best to get
it out of the way now...

- Cole