Hello!
For AARCH64, though... well, if you want to know why it's added for that machinetype, I guess you'd need to talk to the person who turned on addPCIeRoot for AARCH64 :-).
That was me, and i simply reused the existing code. Actually, initially i tried to use addPCIRoot first, but it ended up in a plain PCI bus which does not support MSI-X. Or, even, it did not work at all, because libvirt refers to bus#0 as to just "pci", which does not work with virt. I don't remember the exact outcome. So, i decided to use addPCIeRoot instead, and everything just worked.
I actually wondered about that recently when I was tinkering with auto-adding USB2 controllers when machinetype is Q35 (i.e. "why are we adding an Intel/x86-specific controller to AARCH64 machines?")
I guess we could tweak it so that on non-x86 we have only pcie-root without all the downstream chain. For qemu it will perfectly work, and actually in my XML i put all my devices to bus#0, so that MSI-X works. I don't use downstream buses at all. But, indeed, i never tested hotplugging.
I didn't even know aarch64 migration was working...
It should work out of the box with GICv2, and for GICv3 i posted RFC patches. RFC because kernel API for that is not ready yet.
Is this only a problem on aarch64, or is there a migration problem with pci-bridge on x86 as well? (It's possible there is but it hasn't been noticed, because pci-bridge likely isn't used much outside of q35 machines, and q35 was prohibited from migrating until qemu 2.4 due to the embedded sata driver which didn't support migration.)
I think it should be a generic problem because i don't see how PCI bridge implementation could contain any arch-specific code.
BTW, does the aarch64 virt machinetype support any controller aside from the embedded pcie-root?
No. The actual controller used by "virt" machine is called "generic PCI host", and it registers itself as "pcie.0".
Right now we will auto-add only a pci-bridge if no available slot is found for a pci device, but we will (should anyway) auto-assign a slot on an *existing* PCIe controller if the device has PCIE as the preferred slot type.
AFAIR we already do this. The only problem is that preferred slot type for the device is currently hardcoded to be PCIe for video cards and, IIRC, SCSI; and plain PCI for everything else. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia