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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list