[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: |
Peter Maydell |
Subject: |
Re: [PATCH v7 0/9] target/arm/kvm: enable SVE in guests |
Date: |
Fri, 25 Oct 2019 15:06:12 +0100 |
On Fri, 25 Oct 2019 at 14:52, Andrew Jones <address@hidden> wrote:
>
> On Fri, Oct 25, 2019 at 01:06:26PM +0100, Peter Maydell wrote:
> > Fails 'make check' on my aarch32-compile-in-chroot-on-aarch64
> > machine:
>
> Are there easy-to-follow instructions for setting this environment up
> somewhere?
It's an ancient setup, so not really. But it's just an
Ubuntu 32-bit chroot inside an Ubuntu 64-bit host. I use
schroot to manage it.
> 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.
This all feels like it's trying to do the wrong thing, ie
replicate the logic within QEMU that decides whether to use
KVM or not. Some possible other approaches:
* If you want to know whether you can run the qemu binary
with -accel kvm, then just try that and see if it succeeds.
* Or use '-accel kvm:tcg' and make the test work so that it
will pass for both KVM and TCG
* Or use QMP to query what accelerators are available, assuming
there's a QMP command for that
thanks
-- PMM
- [PATCH v7 4/9] target/arm/cpu64: max cpu: Introduce sve<N> properties, (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