On Fri, 1 Nov 2019 at 14:25, Andrew Jones <drjo...@redhat.com> wrote: > > On Fri, Nov 01, 2019 at 12:53:42PM +0000, Peter Maydell wrote: > > On Fri, 1 Nov 2019 at 10:34, Peter Maydell <peter.mayd...@linaro.org> wrote: > > > > > > On Fri, 1 Nov 2019 at 09:54, Andrew Jones <drjo...@redhat.com> wrote: > > > > Darn it. Sorry about that, but if it's still failing then I think QEMU > > > > must believe KVM is enabled, i.e. kvm_enabled() in QEMU must be true. > > > > I can try to confirm that and fix it, but I'll need to set up this > > > > environment first. > > > > > > Yeah, it looks like trying to run with KVM in an aarch32 chroot > > > doesn't work but we don't notice it -- in qemu kvm_init() succeeds > > > but then we fail when we try to actually create CPUs, so: > > > $ ./arm-softmmu/qemu-system-arm -M virt -M accel=kvm:tcg > > > qemu-system-arm: kvm_init_vcpu failed: Invalid argument > > > > > > we barf rather than falling back to tcg the way we ought to. > > > > I spoke to Christoffer and Marc about this, and they reckoned > > this was basically a kernel bug (and ideally a 64-bit kernel > > should just refuse to open /dev/kvm for an aarch32-compat > > userspace process, because it doesn't provide the aarch32 KVM > > interface, only the aarch64 one). > > > > In the meantime, we should just bodge whatever we need to > > in this test to cause us not to bother to try to run the test, > > in whatever is the most expedient way. > > How about just doing this (which can be cleanly applied to 2/9 > without conflicts on rebase)
Yep, that works. I squashed it in and have applied the updated pullreq. thanks -- PMM