[libvirt] How should libvirt apps enable virtio-pci for aarch64?

[Pavel Fedin]

 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