Re: [PULL 00/11] target-arm queue

[Peter Maydell]

On Fri, 1 Nov 2019 at 14:25, Andrew Jones <address@hidden> wrote:
>
> On Fri, Nov 01, 2019 at 12:53:42PM +0000, Peter Maydell wrote:
> > On Fri, 1 Nov 2019 at 10:34, Peter Maydell <address@hidden> wrote:
> > >
> > > On Fri, 1 Nov 2019 at 09:54, Andrew Jones <address@hidden> 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