[PULL,00/11] target-arm queue

Message ID 20191101085140.5205-1-peter.maydell@linaro.org
Headers show
Series
  • target-arm queue
Related show

Message

Peter Maydell Nov. 1, 2019, 8:51 a.m.
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)

----------------------------------------------------------------
target-arm queue:
 * Support SVE in KVM guests
 * Don't UNDEF on M-profile 'vmrs apsr_nzcv, fpscr'
 * Update hflags after boot.c modifies CPU state

----------------------------------------------------------------
Andrew Jones (9):
      target/arm/monitor: Introduce qmp_query_cpu_model_expansion
      tests: arm: Introduce cpu feature tests
      target/arm: Allow SVE to be disabled via a CPU property
      target/arm/cpu64: max cpu: Introduce sve<N> properties
      target/arm/kvm64: Add kvm_arch_get/put_sve
      target/arm/kvm64: max cpu: Enable SVE when available
      target/arm/kvm: scratch vcpu: Preserve input kvm_vcpu_init features
      target/arm/cpu64: max cpu: Support sve properties with KVM
      target/arm/kvm: host cpu: Add support for sve<N> properties

Christophe Lyon (1):
      target/arm: Allow reading flags from FPSCR for M-profile

Edgar E. Iglesias (1):
      hw/arm/boot: Rebuild hflags when modifying CPUState at boot

 tests/Makefile.include         |   5 +-
 qapi/machine-target.json       |   6 +-
 include/qemu/bitops.h          |   1 +
 target/arm/cpu.h               |  21 ++
 target/arm/kvm_arm.h           |  39 +++
 hw/arm/boot.c                  |   1 +
 target/arm/cpu.c               |  25 +-
 target/arm/cpu64.c             | 364 +++++++++++++++++++++++++--
 target/arm/helper.c            |  10 +-
 target/arm/kvm.c               |  25 +-
 target/arm/kvm32.c             |   6 +-
 target/arm/kvm64.c             | 325 +++++++++++++++++++++---
 target/arm/monitor.c           | 158 ++++++++++++
 target/arm/translate-vfp.inc.c |   5 +-
 tests/arm-cpu-features.c       | 551 +++++++++++++++++++++++++++++++++++++++++
 docs/arm-cpu-features.rst      | 317 ++++++++++++++++++++++++
 16 files changed, 1795 insertions(+), 64 deletions(-)
 create mode 100644 tests/arm-cpu-features.c
 create mode 100644 docs/arm-cpu-features.rst

Comments

Peter Maydell Nov. 1, 2019, 9:30 a.m. | #1
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
Andrew Jones Nov. 1, 2019, 9:54 a.m. | #2
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
Peter Maydell Nov. 1, 2019, 10:34 a.m. | #3
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
Peter Maydell Nov. 1, 2019, 12:53 p.m. | #4
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
Andrew Jones Nov. 1, 2019, 2:25 p.m. | #5
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
Peter Maydell Nov. 2, 2019, 5:57 p.m. | #6
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