qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v7 0/9] target/arm/kvm: enable SVE in guests


From: Andrew Jones
Subject: Re: [PATCH v7 0/9] target/arm/kvm: enable SVE in guests
Date: Fri, 25 Oct 2019 15:51:59 +0200
User-agent: NeoMutt/20180716

On Fri, Oct 25, 2019 at 01:06:26PM +0100, Peter Maydell wrote:
> On Thu, 24 Oct 2019 at 14:42, Peter Maydell <address@hidden> wrote:
> >
> > On Thu, 24 Oct 2019 at 13:18, Andrew Jones <address@hidden> wrote:
> > >
> > > Since Linux kernel v5.2-rc1 KVM has support for enabling SVE in guests.
> > > This series provides the QEMU bits for that enablement. First, we
> > > select existing CPU properties representing features we want to
> > > advertise in addition to the SVE vector lengths and prepare
> > > them for a qmp query. Then we introduce the qmp query, applying
> > > it immediately to those selected features. We also document ARM CPU
> > > features at this time. We next add a qtest for the selected CPU
> > > features that uses the qmp query for its tests - and we continue to
> > > add tests as we add CPU features with the following patches. So then,
> > > once we have the support we need for CPU feature querying and testing,
> > > we add our first SVE CPU feature property, 'sve', which just allows
> > > SVE to be completely enabled/disabled. Following that feature property,
> > > we add all 16 vector length properties along with the input validation
> > > they need and tests to prove the validation works. At this point the
> > > SVE features are still only for TCG, so we provide some patches to
> > > prepare for KVM and then a patch that allows the 'max' CPU type to
> > > enable SVE with KVM, but at first without vector length properties.
> > > After a bit more preparation we add the SVE vector length properties
> > > to the KVM-enabled 'max' CPU type along with the additional input
> > > validation and tests that that needs.  Finally we allow the 'host'
> > > CPU type to also enjoy these properties by simply sharing them with it.
> > >
> >
> >
> >
> > Applied to target-arm.next, thanks.
> 
> Fails 'make check' on my aarch32-compile-in-chroot-on-aarch64
> machine:

Are there easy-to-follow instructions for setting this environment up
somewhere?

> 
> (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

I guess the problem is how we're determining if KVM is available, which
is like this

int main(int argc, char **argv)
{
    bool kvm_available = false;

    if (!access("/dev/kvm",  R_OK | W_OK)) {
#if defined(HOST_AARCH64)
        kvm_available = g_str_equal(qtest_get_arch(), "aarch64");
#elif defined(HOST_ARM)
        kvm_available = g_str_equal(qtest_get_arch(), "arm");
#endif
    }


So we need /dev/kvm and the QEMU binary arch type (qemu-system-arm in
this case) needs to match the host arch type. The problem is that
HOST_<type> doesn't imply anything about the actual host arch type.
<type> comes from the configure $ARCH variable, which for 'arm'
comes from the $cpu variable, which for 'arm' comes from whether or
not the compiler defines __arm__, and cross compilers certainly do.
I guess we'd have the same problem in an aarch32-compile-in-chroot-on-
<any-other-type> environment, if a cross compiler is used for the
compiling. I should change the KVM available check to something that
uses the actual host arch type. I assume the following works, but
I don't know if I'm allowed to use uname() in these tests, and, if
not, then I don't know what the right way to get the actual host
type is.


diff --git a/tests/arm-cpu-features.c b/tests/arm-cpu-features.c
index 6b8c48de8aa8..712af2b405fb 100644
--- a/tests/arm-cpu-features.c
+++ b/tests/arm-cpu-features.c
@@ -13,6 +13,7 @@
 #include "libqtest.h"
 #include "qapi/qmp/qdict.h"
 #include "qapi/qmp/qjson.h"
+#include <sys/utsname.h>
 
 /*
  * We expect the SVE max-vq to be 16. Also it must be <= 64
@@ -506,13 +507,16 @@ static void test_query_cpu_model_expansion_kvm(const void 
*data)
 int main(int argc, char **argv)
 {
     bool kvm_available = false;
+    struct utsname u;
+
+    g_assert(uname(&u) == 0);
 
     if (!access("/dev/kvm",  R_OK | W_OK)) {
-#if defined(HOST_AARCH64)
-        kvm_available = g_str_equal(qtest_get_arch(), "aarch64");
-#elif defined(HOST_ARM)
-        kvm_available = g_str_equal(qtest_get_arch(), "arm");
-#endif
+        if (g_str_equal(u.machine, "aarch64")) {
+            kvm_available = g_str_equal(qtest_get_arch(), "aarch64");
+        } else if (!strncmp(u.machine, "arm", 3)) {
+            kvm_available = g_str_equal(qtest_get_arch(), "arm");
+        }
     }
 
     g_test_init(&argc, &argv, NULL);

> /home/peter.maydell/qemu/tests/libqtest.c:140: kill_qemu() tried to
> terminate QEMU process but encountered exit status 1 (expected 0)
> Aborted
> 
> Dropping again :-(

Sigh...

Thanks,
drew




reply via email to

[Prev in Thread] Current Thread [Next in Thread]