Re: [libvirt] How should libvirt apps enable virtio-pci for aarch64?
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