[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
- Re: [PATCH v7 2/9] tests: arm: Introduce cpu feature tests, (continued)
- [PATCH v7 4/9] target/arm/cpu64: max cpu: Introduce sve<N> properties, Andrew Jones, 2019/10/24
- [PATCH v7 6/9] target/arm/kvm64: max cpu: Enable SVE when available, Andrew Jones, 2019/10/24
- [PATCH v7 3/9] target/arm: Allow SVE to be disabled via a CPU property, Andrew Jones, 2019/10/24
- [PATCH v7 5/9] target/arm/kvm64: Add kvm_arch_get/put_sve, Andrew Jones, 2019/10/24
- [PATCH v7 7/9] target/arm/kvm: scratch vcpu: Preserve input kvm_vcpu_init features, Andrew Jones, 2019/10/24
- [PATCH v7 8/9] target/arm/cpu64: max cpu: Support sve properties with KVM, Andrew Jones, 2019/10/24
- [PATCH v7 9/9] target/arm/kvm: host cpu: Add support for sve<N> properties, Andrew Jones, 2019/10/24
- Re: [PATCH v7 0/9] target/arm/kvm: enable SVE in guests, Peter Maydell, 2019/10/24