The mach-virt model has had a PCIe host bridge since v2.3 (so it's already in qemu-kvm-rhev). The RHELSA kernel now has support for that PCI host bridge when booting using ACPI. So, with backporting the ACPI generation patches to QEMU (bug 1231719), it's possible to boot RHELSA using only virtio-pci (no more virtio-mmio!). It's time to switch the options and defaults in the install tools. (We may need libvirt changes as well, as I couldn't figure out the right XML to convert a libvirt guest to use PCI. It seems libvirt doesn't know that the 'virt' machine type has a PCIe host bridge.)
I guess that there is nothing to do from virt-manager side. The addressing is completely up to libvirt. Virt-manager creates a device with "bus='virtio'" and libvirt will assing best possible address. This bug can be closed and only the libvirt part is relevant. *** This bug has been marked as a duplicate of bug 1244151 ***
we didn't find a way to make this 'just work' in libvirt, so support in the tools is required. virt-manager/virt-install will need to explicitly request <address type='pci'/> if we know the OS supports it. reopening
Right, we decided that this would be based on the guest OS and libosinfo. So this needs to be implemented into virt-manager and ask for pci only for OSes that supports pci for ARM.
Libvirt will use PCI addresses by default since version 3.0.0 so there is nothing for it in virt-manager. However the virt-manager could be improved to decide not to use PCI addresses for older guests or to explicitly ask for PCI addresses if libvirt is older than 3.0.0 and the guest is new enough to support PCI addresses. I'll move this bug to upstream to track this feature. This would also require to add those data into osinfo-db.
In my testing fedora25+ seems to work fine with virtio-pci, but not Fedora 24 (and presumably earlier). Since F24 is EOL in a few months I'm not sure if I care enough to try and make this work :) but maybe other more recent distros still have issues with virtio-pci, so I'll leave this open for a while
No one has ever once complained about this in practice, so I don't think it's worth worrying about in virt-install/virt-manager