Message ID | 20191101085140.5205-1-peter.maydell@linaro.org |
---|---|
Headers | show |
Series | target-arm queue | expand |
On Fri, 1 Nov 2019 at 08:51, Peter Maydell <peter.maydell@linaro.org> wrote: > > target-arm queue: two bug fixes, plus the KVM/SVE patchset, > which is a new feature but one which was in my pre-softfreeze > pullreq (it just had to be dropped due to an unexpected test failure.) > > thanks > -- PMM > > The following changes since commit b7c9a7f353c0e260519bf735ff0d4aa01e72784b: > > Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into staging (2019-10-31 15:57:30 +0000) > > are available in the Git repository at: > > https://git.linaro.org/people/pmaydell/qemu-arm.git tags/pull-target-arm-20191101-1 > > for you to fetch changes up to d9ae7624b659362cb2bb2b04fee53bf50829ca56: > > target/arm: Allow reading flags from FPSCR for M-profile (2019-11-01 08:49:10 +0000) Drew, this is still failing 'make check' on the aarch32-chroot-on-aarch64 :-( (armhf)pmaydell@mustang-maydell:~/qemu/build/all-a32$ QTEST_QEMU_BINARY=arm-softmmu/qemu-system-arm ./tests/arm-cpu-features /arm/arm/query-cpu-model-expansion: OK /arm/arm/kvm/query-cpu-model-expansion: qemu-system-arm: Failed to retrieve host CPU features Broken pipe /home/peter.maydell/qemu/tests/libqtest.c:140: kill_qemu() tried to terminate QEMU process but encountered exit status 1 (expected 0) Aborted thanks -- PMM
On Fri, Nov 01, 2019 at 09:30:21AM +0000, Peter Maydell wrote: > On Fri, 1 Nov 2019 at 08:51, Peter Maydell <peter.maydell@linaro.org> wrote: > > > > target-arm queue: two bug fixes, plus the KVM/SVE patchset, > > which is a new feature but one which was in my pre-softfreeze > > pullreq (it just had to be dropped due to an unexpected test failure.) > > > > thanks > > -- PMM > > > > The following changes since commit b7c9a7f353c0e260519bf735ff0d4aa01e72784b: > > > > Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into staging (2019-10-31 15:57:30 +0000) > > > > are available in the Git repository at: > > > > https://git.linaro.org/people/pmaydell/qemu-arm.git tags/pull-target-arm-20191101-1 > > > > for you to fetch changes up to d9ae7624b659362cb2bb2b04fee53bf50829ca56: > > > > target/arm: Allow reading flags from FPSCR for M-profile (2019-11-01 08:49:10 +0000) > > Drew, this is still failing 'make check' on the aarch32-chroot-on-aarch64 :-( > > (armhf)pmaydell@mustang-maydell:~/qemu/build/all-a32$ > QTEST_QEMU_BINARY=arm-softmmu/qemu-system-arm ./tests/arm-cpu-features > /arm/arm/query-cpu-model-expansion: OK > /arm/arm/kvm/query-cpu-model-expansion: qemu-system-arm: Failed to > retrieve host CPU features > Broken pipe > /home/peter.maydell/qemu/tests/libqtest.c:140: kill_qemu() tried to > terminate QEMU process but encountered exit status 1 (expected 0) > Aborted > 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. Thanks, drew
On Fri, 1 Nov 2019 at 09:54, Andrew Jones <drjones@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. Does i386-on-x86_64 KVM handle this case? thanks -- PMM
On Fri, 1 Nov 2019 at 10:34, Peter Maydell <peter.maydell@linaro.org> wrote: > > On Fri, 1 Nov 2019 at 09:54, Andrew Jones <drjones@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. thanks -- PMM
On Fri, Nov 01, 2019 at 12:53:42PM +0000, Peter Maydell wrote: > On Fri, 1 Nov 2019 at 10:34, Peter Maydell <peter.maydell@linaro.org> wrote: > > > > On Fri, 1 Nov 2019 at 09:54, Andrew Jones <drjones@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) Thanks, drew From 9c5358d03528ea8a46731dcc4cfafb160ff66b5c Mon Sep 17 00:00:00 2001 From: Andrew Jones <drjones@redhat.com> 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
On Fri, 1 Nov 2019 at 14:25, Andrew Jones <drjones@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.maydell@linaro.org> wrote: > > > > > > On Fri, 1 Nov 2019 at 09:54, Andrew Jones <drjones@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