Re: [libvirt] ARMv7 guest PCI support broken in 3.0.0 onwards
On Thu, 2017-02-16 at 16:13 +0000, Daniel P. Berrange wrote:
> I'm asking because I've just spent some time trying to
run
> ARM guests[1] on my laptop[2] and I can't reproduce the
> failure you're describing, so I need more information to
> try and narrow it down.
my favourite type of bug :-)
You mean everyone's ;)
Thanks to the additional information, though, I've managed
to pinpoint the issue:
<features>
<gic version='3'/>
</features>
libvirt is picking GICv3 here because QEMU reports it as a
viable emulated GIC; however, as I understand it the
emulated GICv3 doesn't have MSI support, and without that
PCIe can't work. If you manually switch to GICv2 you should
be able to run the guest succesfully.
We should find a way to detect whether the interrupt
controller will support PCIe, and fall back to using
virtio-mmio when it doesn't. Eric, any ideas about how we
could achieve that?
> I would expect such an error to pop up simply by running
>
> $ qemu-system-arm -nodefaults -M virt \
> -device ioh3420,port=0x8,...
>
> Does that happen on your system?
That gets a segmentation fault !
I've managed to reproduce this one too, with both QEMU
2.7.1 and 2.8.0: running
$ qemu-system-{aarch64,arm} \
-nodefaults \
-M virt \
-device ioh3420
is enough to crash it during GTK+ initialization, but
if you add
-display none
(which libvirt will) if works fine.
The bug seems to have been fixed in master; I would
recommend filing a bug against Fedora to get them to
backport it if possible.
> I know 32-bit UEFI is a thing, because it's used on a bunch
> of budget x86 tablet and causes grief and pain to anyone
> trying to run Linux on them. However, Fedora only ships
> 64-bit binaries (edk2-ovmf and edk2-aarch64 packages) so I
> can't really try whether an armv7l guest can boot using UEFI.
Does -M Virt require UEFI ? I thought those were orthoganol
choices.
They are: I've successfully booted both armv7l and aarch64
mach-virt guests with no UEFI involved.
> Speaking of booting the guest, how would that work with the
> guest XML you're feeding libvirt, exactly? Since you don't
> have any sort of firmware, the only way I can see it working
> is to to have <kernel>, <initrd> and <cmdline> elements
> inside <domain><os>, and libvirt can't possibly figure out
> their values for you...
That is correct - it can't boot, it needs kernel/initrd.
I'd be happy if QEMU actually got far enough to tell me
I forgot to give it a kernel or firmware :-)
Okay, so when you say that it worked with 2.5.0 you really
just mean that libvirt got as far as launching QEMU without
it returning an error right away, not that the guest
actually booted all the way to a shell. That makes sense :)
--
Andrea Bolognani / Red Hat / Virtualization