[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PULL 00/11] target-arm queue
From: |
Andrew Jones |
Subject: |
Re: [PULL 00/11] target-arm queue |
Date: |
Fri, 1 Nov 2019 15:25:40 +0100 |
User-agent: |
NeoMutt/20180716 |
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)
Thanks,
drew
>From 9c5358d03528ea8a46731dcc4cfafb160ff66b5c Mon Sep 17 00:00:00 2001
From: Andrew Jones <address@hidden>
Date: Fri, 1 Nov 2019 15:18:46 +0100
Subject: [PATCH v8 10/9] fixup! tests: arm: Introduce cpu feature tests
---
tests/arm-cpu-features.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/tests/arm-cpu-features.c b/tests/arm-cpu-features.c
index b132ed09806d..ec33d58e1367 100644
--- a/tests/arm-cpu-features.c
+++ b/tests/arm-cpu-features.c
@@ -535,8 +535,16 @@ int main(int argc, char **argv)
qtest_add_data_func("/arm/query-cpu-model-expansion",
NULL, test_query_cpu_model_expansion);
- qtest_add_data_func("/arm/kvm/query-cpu-model-expansion",
- NULL, test_query_cpu_model_expansion_kvm);
+
+ /*
+ * For now we only run KVM specific tests with AArch64 QEMU in
+ * order avoid attempting to run an AArch32 QEMU with KVM on
+ * AArch64 hosts. That won't work and isn't easy to detect.
+ */
+ if (g_str_equal(qtest_get_arch(), "aarch64")) {
+ qtest_add_data_func("/arm/kvm/query-cpu-model-expansion",
+ NULL, test_query_cpu_model_expansion_kvm);
+ }
if (g_str_equal(qtest_get_arch(), "aarch64")) {
qtest_add_data_func("/arm/max/query-cpu-model-expansion/sve-max-vq-8",
--
2.21.0
- [PULL 04/11] target/arm/cpu64: max cpu: Introduce sve<N> properties, (continued)
[PULL 08/11] target/arm/cpu64: max cpu: Support sve properties with KVM, Peter Maydell, 2019/11/01
Re: [PULL 00/11] target-arm queue, Peter Maydell, 2019/11/01