From: Mario Smarduch <m.smarduch@samsung.com>
To: Marc Zyngier <marc.zyngier@arm.com>,
Christoffer Dall <christoffer.dall@linaro.org>
Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Russell King - ARM Linux <linux@arm.linux.org.uk>
Subject: Re: [PATCH v6 1/6] arm/arm64: KVM: Introduce armv7 fp/simd vcpu fields and helpers
Date: Fri, 15 Jan 2016 17:21:23 -0800 [thread overview]
Message-ID: <56999B13.6050103@samsung.com> (raw)
In-Reply-To: <5698B5C9.4030404@arm.com>
On 1/15/2016 1:03 AM, Marc Zyngier wrote:
> On 15/01/16 02:02, Mario Smarduch wrote:
>>
>>
>> On 1/14/2016 5:27 AM, Christoffer Dall wrote:
>>> On Wed, Jan 13, 2016 at 07:03:04PM -0800, Mario Smarduch wrote:
>>>>
>>>>
>>>> On 1/12/2016 4:57 PM, Mario Smarduch wrote:
>>>>>
>>>>>
>>>>> On 1/12/2016 6:12 AM, Christoffer Dall wrote:
>>>>>> On Mon, Jan 11, 2016 at 03:39:21PM -0800, Mario Smarduch wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 1/10/2016 8:32 AM, Christoffer Dall wrote:
>>>>>>>> Hi Mario,
>>>>>>>>
>>>>>>>> I spotted one more potential issue...
>>>>>>>>
>>>>>>>> On Sat, Dec 26, 2015 at 01:54:55PM -0800, Mario Smarduch wrote:
>>>>>>>>> Add helper functions to enable access to fp/smid on guest entry and save host
>>>>>>>>> fpexc on vcpu put, check if fp/simd registers are dirty and add new vcpu
>>>>>>>>> fields.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Mario Smarduch <m.smarduch@samsung.com>
>>>>>>>>> ---
>>>>>>>>> arch/arm/include/asm/kvm_emulate.h | 42 ++++++++++++++++++++++++++++++++++++
>>>>>>>>> arch/arm/include/asm/kvm_host.h | 6 ++++++
>>>>>>>>> arch/arm64/include/asm/kvm_emulate.h | 8 +++++++
>>>>>>>>> 3 files changed, 56 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git a/arch/arm/include/asm/kvm_emulate.h b/arch/arm/include/asm/kvm_emulate.h
>>>>>>>>> index 3095df0..d4d9da1 100644
>>>>>>>>> --- a/arch/arm/include/asm/kvm_emulate.h
>>>>>>>>> +++ b/arch/arm/include/asm/kvm_emulate.h
>>>>>>>>> @@ -24,6 +24,8 @@
>>>>>>>>> #include <asm/kvm_mmio.h>
>>>>>>>>> #include <asm/kvm_arm.h>
>>>>>>>>> #include <asm/cputype.h>
>>>>>>>>> +#include <asm/vfp.h>
>>>>>>>>> +#include "../vfp/vfpinstr.h"
>>>>>>>>>
>>>>>>>>> unsigned long *vcpu_reg(struct kvm_vcpu *vcpu, u8 reg_num);
>>>>>>>>> unsigned long *vcpu_spsr(struct kvm_vcpu *vcpu);
>>>>>>>>> @@ -255,4 +257,44 @@ static inline unsigned long vcpu_data_host_to_guest(struct kvm_vcpu *vcpu,
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> +#ifdef CONFIG_VFPv3
>>>>>>>>> +/* Called from vcpu_load - save fpexc and enable guest access to fp/simd unit */
>>>>>>>>> +static inline void vcpu_trap_vfp_enable(struct kvm_vcpu *vcpu)
>>>>>>>>> +{
>>>>>>>>> + u32 fpexc;
>>>>>>>>> +
>>>>>>>>> + /* Save host fpexc, and enable guest access to fp unit */
>>>>>>>>> + fpexc = fmrx(FPEXC);
>>>>>>>>> + vcpu->arch.host_fpexc = fpexc;
>>>>>>>>> + fpexc |= FPEXC_EN;
>>>>>>>>> + fmxr(FPEXC, fpexc);
>>>>>>>>> +
>>>>>>>>> + /* Configure HCPTR to trap on tracing and fp/simd access */
>>>>>>>>> + vcpu->arch.hcptr = HCPTR_TTA | HCPTR_TCP(10) | HCPTR_TCP(11);
>>>>>>>>> +}
>>>>>>>>> +
>>>>>>>>> +/* Called from vcpu_put - restore host fpexc */
>>>>>>>>> +static inline void vcpu_restore_host_fpexc(struct kvm_vcpu *vcpu)
>>>>>>>>> +{
>>>>>>>>> + fmxr(FPEXC, vcpu->arch.host_fpexc);
>>>>>>>>> +}
>>>>>>>>> +
>>>>>>>>> +/* If trap bits are reset then fp/simd registers are dirty */
>>>>>>>>> +static inline bool vcpu_vfp_isdirty(struct kvm_vcpu *vcpu)
>>>>>>>>> +{
>>>>>>>>> + return !(vcpu->arch.hcptr & (HCPTR_TCP(10) | HCPTR_TCP(11)));
>>>>>>>>> +}
>>>>>>>>> +#else
>>>>>>>>> +static inline void vcpu_trap_vfp_enable(struct kvm_vcpu *vcpu)
>>>>>>>>> +{
>>>>>>>>> + vcpu->arch.hcptr = HCPTR_TTA;
>>>>>>>>
>>>>>>>> Is it correct not to trap VFP registers when the host kernel does not
>>>>>>>> have CONFIG_VFPv3? I think this is a change in functionality compared
>>>>>>>> to the current kernels is it not?
>>>>>>>
>>>>>>> With CPU_V7 VFPv3 gets selected, without it fp should be emulated,
>>>>>>> with exceptions taken in guest kernel. I don't see a reason why
>>>>>>> fp hcptr access should be enabled in that case.
>>>>>>>
>>>>>>
>>>>>> If you have to guests with CONFIG_VFPV3 but your host doesn't have
>>>>>> CONFIG_VFPV3, you will never context-switch the VFP registers between
>>>>>> the two VMs, and mayhem will ensue.
>>>>>>
>>>>>> Unless I'm missing something very obvious?
>>>>
>>>> Did more testing on this enabling OABI_COMPAT and selecting
>>>> NWFPE/FastFPE breaks the boot. So far can't find a way to boot host
>>>> without VFP/VFPv3 enabled on ARMv7. CPU_V7 defaults to VFPv3
>>>> selection. I'm wondering if !VFPv3 path should be removed from
>>>> the patches?
>>>>
>>> I think this is related to your particular choice of userspace.
>>
>> It appears like there are two soft float implementations.
>>
>> FastFPE - but that's missing arch/arm/fastfpe directory, the option
>> can still be selected but nothing is built.
>>
>> And the Netwidner FPE arch/arm/nwfpe, that doesn't appear to be
>> hooked into the kernel. The hook nwfpe_enter is not referenced
>> anywhere.
>
> It is:
>
> arch/arm/nwfpe/entry.S: .globl nwfpe_enter
> arch/arm/nwfpe/entry.S:nwfpe_enter:
> arch/arm/nwfpe/fpmodule.c:extern void nwfpe_enter(void);
> arch/arm/nwfpe/fpmodule.c: kern_fp_enter = nwfpe_enter;
>
>> I could make this change but have no way to bring the host up to
>> test it.
>
> None of these are relevant - they are emulation for the FPA (Floating
> Point Accelerator). Most of the time, nobody uses this but instead a
> userspace softfloat implementation, which saves the trap to kernel space
> for emulation.
>
> You can try Debian armel (as opposed to armhf, which mandates VFP) for
> example, which is a softfloat-based distribution.
I've been using armel debian but it appears some binaries have hard fp
instructions (-mfloat-abi=hard,softfp). I have a simple rootfs now and
it comes up cleanly on the host. I'll work on qemu now.
Thanks for pointing out FPA.
- Mario
>
> Thanks,
>
> M.
>
WARNING: multiple messages have this Message-ID (diff)
From: m.smarduch@samsung.com (Mario Smarduch)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 1/6] arm/arm64: KVM: Introduce armv7 fp/simd vcpu fields and helpers
Date: Fri, 15 Jan 2016 17:21:23 -0800 [thread overview]
Message-ID: <56999B13.6050103@samsung.com> (raw)
In-Reply-To: <5698B5C9.4030404@arm.com>
On 1/15/2016 1:03 AM, Marc Zyngier wrote:
> On 15/01/16 02:02, Mario Smarduch wrote:
>>
>>
>> On 1/14/2016 5:27 AM, Christoffer Dall wrote:
>>> On Wed, Jan 13, 2016 at 07:03:04PM -0800, Mario Smarduch wrote:
>>>>
>>>>
>>>> On 1/12/2016 4:57 PM, Mario Smarduch wrote:
>>>>>
>>>>>
>>>>> On 1/12/2016 6:12 AM, Christoffer Dall wrote:
>>>>>> On Mon, Jan 11, 2016 at 03:39:21PM -0800, Mario Smarduch wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 1/10/2016 8:32 AM, Christoffer Dall wrote:
>>>>>>>> Hi Mario,
>>>>>>>>
>>>>>>>> I spotted one more potential issue...
>>>>>>>>
>>>>>>>> On Sat, Dec 26, 2015 at 01:54:55PM -0800, Mario Smarduch wrote:
>>>>>>>>> Add helper functions to enable access to fp/smid on guest entry and save host
>>>>>>>>> fpexc on vcpu put, check if fp/simd registers are dirty and add new vcpu
>>>>>>>>> fields.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Mario Smarduch <m.smarduch@samsung.com>
>>>>>>>>> ---
>>>>>>>>> arch/arm/include/asm/kvm_emulate.h | 42 ++++++++++++++++++++++++++++++++++++
>>>>>>>>> arch/arm/include/asm/kvm_host.h | 6 ++++++
>>>>>>>>> arch/arm64/include/asm/kvm_emulate.h | 8 +++++++
>>>>>>>>> 3 files changed, 56 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git a/arch/arm/include/asm/kvm_emulate.h b/arch/arm/include/asm/kvm_emulate.h
>>>>>>>>> index 3095df0..d4d9da1 100644
>>>>>>>>> --- a/arch/arm/include/asm/kvm_emulate.h
>>>>>>>>> +++ b/arch/arm/include/asm/kvm_emulate.h
>>>>>>>>> @@ -24,6 +24,8 @@
>>>>>>>>> #include <asm/kvm_mmio.h>
>>>>>>>>> #include <asm/kvm_arm.h>
>>>>>>>>> #include <asm/cputype.h>
>>>>>>>>> +#include <asm/vfp.h>
>>>>>>>>> +#include "../vfp/vfpinstr.h"
>>>>>>>>>
>>>>>>>>> unsigned long *vcpu_reg(struct kvm_vcpu *vcpu, u8 reg_num);
>>>>>>>>> unsigned long *vcpu_spsr(struct kvm_vcpu *vcpu);
>>>>>>>>> @@ -255,4 +257,44 @@ static inline unsigned long vcpu_data_host_to_guest(struct kvm_vcpu *vcpu,
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> +#ifdef CONFIG_VFPv3
>>>>>>>>> +/* Called from vcpu_load - save fpexc and enable guest access to fp/simd unit */
>>>>>>>>> +static inline void vcpu_trap_vfp_enable(struct kvm_vcpu *vcpu)
>>>>>>>>> +{
>>>>>>>>> + u32 fpexc;
>>>>>>>>> +
>>>>>>>>> + /* Save host fpexc, and enable guest access to fp unit */
>>>>>>>>> + fpexc = fmrx(FPEXC);
>>>>>>>>> + vcpu->arch.host_fpexc = fpexc;
>>>>>>>>> + fpexc |= FPEXC_EN;
>>>>>>>>> + fmxr(FPEXC, fpexc);
>>>>>>>>> +
>>>>>>>>> + /* Configure HCPTR to trap on tracing and fp/simd access */
>>>>>>>>> + vcpu->arch.hcptr = HCPTR_TTA | HCPTR_TCP(10) | HCPTR_TCP(11);
>>>>>>>>> +}
>>>>>>>>> +
>>>>>>>>> +/* Called from vcpu_put - restore host fpexc */
>>>>>>>>> +static inline void vcpu_restore_host_fpexc(struct kvm_vcpu *vcpu)
>>>>>>>>> +{
>>>>>>>>> + fmxr(FPEXC, vcpu->arch.host_fpexc);
>>>>>>>>> +}
>>>>>>>>> +
>>>>>>>>> +/* If trap bits are reset then fp/simd registers are dirty */
>>>>>>>>> +static inline bool vcpu_vfp_isdirty(struct kvm_vcpu *vcpu)
>>>>>>>>> +{
>>>>>>>>> + return !(vcpu->arch.hcptr & (HCPTR_TCP(10) | HCPTR_TCP(11)));
>>>>>>>>> +}
>>>>>>>>> +#else
>>>>>>>>> +static inline void vcpu_trap_vfp_enable(struct kvm_vcpu *vcpu)
>>>>>>>>> +{
>>>>>>>>> + vcpu->arch.hcptr = HCPTR_TTA;
>>>>>>>>
>>>>>>>> Is it correct not to trap VFP registers when the host kernel does not
>>>>>>>> have CONFIG_VFPv3? I think this is a change in functionality compared
>>>>>>>> to the current kernels is it not?
>>>>>>>
>>>>>>> With CPU_V7 VFPv3 gets selected, without it fp should be emulated,
>>>>>>> with exceptions taken in guest kernel. I don't see a reason why
>>>>>>> fp hcptr access should be enabled in that case.
>>>>>>>
>>>>>>
>>>>>> If you have to guests with CONFIG_VFPV3 but your host doesn't have
>>>>>> CONFIG_VFPV3, you will never context-switch the VFP registers between
>>>>>> the two VMs, and mayhem will ensue.
>>>>>>
>>>>>> Unless I'm missing something very obvious?
>>>>
>>>> Did more testing on this enabling OABI_COMPAT and selecting
>>>> NWFPE/FastFPE breaks the boot. So far can't find a way to boot host
>>>> without VFP/VFPv3 enabled on ARMv7. CPU_V7 defaults to VFPv3
>>>> selection. I'm wondering if !VFPv3 path should be removed from
>>>> the patches?
>>>>
>>> I think this is related to your particular choice of userspace.
>>
>> It appears like there are two soft float implementations.
>>
>> FastFPE - but that's missing arch/arm/fastfpe directory, the option
>> can still be selected but nothing is built.
>>
>> And the Netwidner FPE arch/arm/nwfpe, that doesn't appear to be
>> hooked into the kernel. The hook nwfpe_enter is not referenced
>> anywhere.
>
> It is:
>
> arch/arm/nwfpe/entry.S: .globl nwfpe_enter
> arch/arm/nwfpe/entry.S:nwfpe_enter:
> arch/arm/nwfpe/fpmodule.c:extern void nwfpe_enter(void);
> arch/arm/nwfpe/fpmodule.c: kern_fp_enter = nwfpe_enter;
>
>> I could make this change but have no way to bring the host up to
>> test it.
>
> None of these are relevant - they are emulation for the FPA (Floating
> Point Accelerator). Most of the time, nobody uses this but instead a
> userspace softfloat implementation, which saves the trap to kernel space
> for emulation.
>
> You can try Debian armel (as opposed to armhf, which mandates VFP) for
> example, which is a softfloat-based distribution.
I've been using armel debian but it appears some binaries have hard fp
instructions (-mfloat-abi=hard,softfp). I have a simple rootfs now and
it comes up cleanly on the host. I'll work on qemu now.
Thanks for pointing out FPA.
- Mario
>
> Thanks,
>
> M.
>
next prev parent reply other threads:[~2016-01-16 1:21 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-26 21:54 [PATCH v6 0/6] arm/arm64: KVM: Enhance armv7/8 fp/simd lazy switch Mario Smarduch
2015-12-26 21:54 ` Mario Smarduch
2015-12-26 21:54 ` [PATCH v6 1/6] arm/arm64: KVM: Introduce armv7 fp/simd vcpu fields and helpers Mario Smarduch
2015-12-26 21:54 ` Mario Smarduch
2016-01-05 15:00 ` Christoffer Dall
2016-01-05 15:00 ` Christoffer Dall
2016-01-05 19:28 ` Mario Smarduch
2016-01-05 19:28 ` Mario Smarduch
2016-01-10 16:32 ` Christoffer Dall
2016-01-10 16:32 ` Christoffer Dall
2016-01-11 23:17 ` Mario Smarduch
2016-01-11 23:17 ` Mario Smarduch
2016-01-10 16:32 ` Christoffer Dall
2016-01-10 16:32 ` Christoffer Dall
2016-01-11 23:39 ` Mario Smarduch
2016-01-11 23:39 ` Mario Smarduch
2016-01-12 14:12 ` Christoffer Dall
2016-01-12 14:12 ` Christoffer Dall
2016-01-13 0:57 ` Mario Smarduch
2016-01-13 0:57 ` Mario Smarduch
2016-01-14 3:03 ` Mario Smarduch
2016-01-14 3:03 ` Mario Smarduch
2016-01-14 13:27 ` Christoffer Dall
2016-01-14 13:27 ` Christoffer Dall
2016-01-14 13:55 ` Marc Zyngier
2016-01-14 13:55 ` Marc Zyngier
2016-01-15 2:02 ` Mario Smarduch
2016-01-15 2:02 ` Mario Smarduch
2016-01-15 9:03 ` Marc Zyngier
2016-01-15 9:03 ` Marc Zyngier
2016-01-16 1:21 ` Mario Smarduch [this message]
2016-01-16 1:21 ` Mario Smarduch
2016-01-21 2:29 ` Mario Smarduch
2016-01-21 2:29 ` Mario Smarduch
2015-12-26 21:54 ` [PATCH v6 2/6] arm: KVM: Introduce host fp/simd context switch function Mario Smarduch
2015-12-26 21:54 ` Mario Smarduch
2016-01-10 16:31 ` Christoffer Dall
2016-01-10 16:31 ` Christoffer Dall
2015-12-26 21:54 ` [PATCH v6 3/6] arm/arm64: KVM: Enable armv7 fp/simd enhanced context switch Mario Smarduch
2015-12-26 21:54 ` Mario Smarduch
2016-01-10 16:32 ` Christoffer Dall
2016-01-10 16:32 ` Christoffer Dall
2015-12-26 21:54 ` [PATCH v6 4/6] arm: KVM: Delete unused macros Mario Smarduch
2015-12-26 21:54 ` Mario Smarduch
2016-01-10 16:32 ` Christoffer Dall
2016-01-10 16:32 ` Christoffer Dall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56999B13.6050103@samsung.com \
--to=m.smarduch@samsung.com \
--cc=christoffer.dall@linaro.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--cc=marc.zyngier@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.