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