[RFT - PATCH v2 0/2] KVM/arm64: add fp/simd lazy switch support

[RFT - PATCH v2 0/2] KVM/arm64: add fp/simd lazy switch support

[Mario Smarduch]

This is a 2nd itteration for arm64, v1 patches were posted by mistake from an 
older branch which included several bugs. Hopefully didn't waste too much of 
anyones time.

This patch series is a followup to the armv7 fp/simd lazy switch
implementation, uses similar approach and depends on the series - see
https://lists.cs.columbia.edu/pipermail/kvmarm/2015-September/016516.html

It's based on earlier arm64 fp/simd optimization work - see
https://lists.cs.columbia.edu/pipermail/kvmarm/2015-July/015748.html

And subsequent fixes by Marc and Christoffer at KVM Forum hackathon to handle
32-bit guest on 64 bit host (and may require more here) - see
https://lists.cs.columbia.edu/pipermail/kvmarm/2015-August/016128.html

This series has be tested with arm64 on arm64 with several FP applications 
running on host and guest, with substantial decrease on number of 
fp/simd context switches. From about 30% down to 2% with one guest running.

At this time I don't have arm32/arm64 working and hoping Christoffer and/or
Marc (or anyone) can test 32-bit guest/64-bit host.

Mario Smarduch (2):
  add hooks for armv8 fp/simd lazy switch
  enable armv8 fp/simd lazy switch

 arch/arm/kvm/arm.c                |  2 --
 arch/arm64/include/asm/kvm_asm.h  |  1 +
 arch/arm64/include/asm/kvm_host.h |  3 ++
 arch/arm64/kernel/asm-offsets.c   |  1 +
 arch/arm64/kvm/hyp.S              | 58 ++++++++++++++++++++++++++-------------
 5 files changed, 44 insertions(+), 21 deletions(-)

-- 
1.9.1

[RFT - PATCH v2 1/2] add hooks for armv8 fp/simd lazy switch

[Mario Smarduch]

This patch adds hooks to support fp/simd lazy switch. A vcpu flag to track
fp/simd state, and flag offset in vcpu structure.

Signed-off-by: Mario Smarduch <m.smarduch@samsung.com>
---
 arch/arm64/include/asm/kvm_host.h | 3 +++
 arch/arm64/kernel/asm-offsets.c   | 1 +
 2 files changed, 4 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 415938d..f4665e5 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -161,6 +161,9 @@ struct kvm_vcpu_arch {
 	/* Interrupt related fields */
 	u64 irq_lines;		/* IRQ and FIQ levels */
 
+	/* Track fp/simd lazy switch */
+	u32 vfp_lazy;
+
 	/* Cache some mmu pages needed inside spinlock regions */
 	struct kvm_mmu_memory_cache mmu_page_cache;
 
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 8d89cf8..8311da4 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -124,6 +124,7 @@ int main(void)
   DEFINE(VCPU_HCR_EL2,		offsetof(struct kvm_vcpu, arch.hcr_el2));
   DEFINE(VCPU_MDCR_EL2,	offsetof(struct kvm_vcpu, arch.mdcr_el2));
   DEFINE(VCPU_IRQ_LINES,	offsetof(struct kvm_vcpu, arch.irq_lines));
+  DEFINE(VCPU_VFP_LAZY,         offsetof(struct kvm_vcpu, arch.vfp_lazy));
   DEFINE(VCPU_HOST_CONTEXT,	offsetof(struct kvm_vcpu, arch.host_cpu_context));
   DEFINE(VCPU_HOST_DEBUG_STATE, offsetof(struct kvm_vcpu, arch.host_debug_state));
   DEFINE(VCPU_TIMER_CNTV_CTL,	offsetof(struct kvm_vcpu, arch.timer_cpu.cntv_ctl));
-- 
1.9.1

[RFT - PATCH v2 2/2] enable armv8 fp/simd lazy switch

[Mario Smarduch]

This patch enables arm64 lazy fp/simd switch. Removes the ARM constraint,
and follows the same approach as armv7 version - found here

https://lists.cs.columbia.edu/pipermail/kvmarm/2015-September/016518.html

To summarize - provided the guest accesses fp/simd unit we limit number of 
fp/simd context switches to one per vCPU scheduled execution.

Signed-off-by: Mario Smarduch <m.smarduch@samsung.com>
---
 arch/arm/kvm/arm.c               |  2 --
 arch/arm64/include/asm/kvm_asm.h |  1 +
 arch/arm64/kvm/hyp.S             | 58 +++++++++++++++++++++++++++-------------
 3 files changed, 40 insertions(+), 21 deletions(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 0acbb69..7260853 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -112,12 +112,10 @@ void kvm_arch_check_processor_compat(void *rtn)
  */
 static void kvm_switch_fp_regs(struct kvm_vcpu *vcpu)
 {
-#ifdef CONFIG_ARM
 	if (vcpu->arch.vfp_lazy == 1) {
 		kvm_call_hyp(__kvm_restore_host_vfp_state, vcpu);
 		vcpu->arch.vfp_lazy = 0;
 	}
-#endif
 }
 
 /**
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 67fa0de..7d9936b 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -119,6 +119,7 @@ extern char __kvm_hyp_vector[];
 extern void __kvm_flush_vm_context(void);
 extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
 extern void __kvm_tlb_flush_vmid(struct kvm *kvm);
+extern void __kvm_restore_host_vfp_state(struct kvm_vcpu *vcpu);
 
 extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
 
diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
index 39aa322..2273916 100644
--- a/arch/arm64/kvm/hyp.S
+++ b/arch/arm64/kvm/hyp.S
@@ -385,14 +385,6 @@
 	tbz	\tmp, #KVM_ARM64_DEBUG_DIRTY_SHIFT, \target
 .endm
 
-/*
- * Branch to target if CPTR_EL2.TFP bit is set (VFP/SIMD trapping enabled)
- */
-.macro skip_fpsimd_state tmp, target
-	mrs	\tmp, cptr_el2
-	tbnz	\tmp, #CPTR_EL2_TFP_SHIFT, \target
-.endm
-
 .macro compute_debug_state target
 	// Compute debug state: If any of KDE, MDE or KVM_ARM64_DEBUG_DIRTY
 	// is set, we do a full save/restore cycle and disable trapping.
@@ -433,10 +425,6 @@
 	mrs	x5, ifsr32_el2
 	stp	x4, x5, [x3]
 
-	skip_fpsimd_state x8, 3f
-	mrs	x6, fpexc32_el2
-	str	x6, [x3, #16]
-3:
 	skip_debug_state x8, 2f
 	mrs	x7, dbgvcr32_el2
 	str	x7, [x3, #24]
@@ -495,8 +483,14 @@
 	isb
 99:
 	msr     hcr_el2, x2
-	mov	x2, #CPTR_EL2_TTA
+
+	mov     x2, #0
+	ldr     x3, [x0, #VCPU_VFP_LAZY]
+	tbnz    x3, #0, 98f
+
 	orr     x2, x2, #CPTR_EL2_TFP
+98:
+	orr     x2, x2, #CPTR_EL2_TTA
 	msr	cptr_el2, x2
 
 	mov	x2, #(1 << 15)	// Trap CP15 Cr=15
@@ -674,14 +668,12 @@ __restore_debug:
 	ret
 
 __save_fpsimd:
-	skip_fpsimd_state x3, 1f
 	save_fpsimd
-1:	ret
+	ret
 
 __restore_fpsimd:
-	skip_fpsimd_state x3, 1f
 	restore_fpsimd
-1:	ret
+	ret
 
 switch_to_guest_fpsimd:
 	push	x4, lr
@@ -693,6 +685,9 @@ switch_to_guest_fpsimd:
 
 	mrs	x0, tpidr_el2
 
+	mov     x2, #1
+	str     x2, [x0, #VCPU_VFP_LAZY]
+
 	ldr	x2, [x0, #VCPU_HOST_CONTEXT]
 	kern_hyp_va x2
 	bl __save_fpsimd
@@ -768,7 +763,6 @@ __kvm_vcpu_return:
 	add	x2, x0, #VCPU_CONTEXT
 
 	save_guest_regs
-	bl __save_fpsimd
 	bl __save_sysregs
 
 	skip_debug_state x3, 1f
@@ -789,7 +783,6 @@ __kvm_vcpu_return:
 	kern_hyp_va x2
 
 	bl __restore_sysregs
-	bl __restore_fpsimd
 	/* Clear FPSIMD and Trace trapping */
 	msr     cptr_el2, xzr
 
@@ -868,6 +861,33 @@ ENTRY(__kvm_flush_vm_context)
 	ret
 ENDPROC(__kvm_flush_vm_context)
 
+/**
+ * kvm_switch_fp_regs() - switch guest/host VFP/SIMD registers
+ * @vcpu:      pointer to vcpu structure.
+ *
+ */
+ENTRY(__kvm_restore_host_vfp_state)
+	push    x4, lr
+
+	kern_hyp_va x0
+	add     x2, x0, #VCPU_CONTEXT
+
+	// Load Guest HCR, determine if guest is 32 or 64 bit
+	ldr     x3, [x0, #VCPU_HCR_EL2]
+	tbnz	x3, #HCR_RW_SHIFT, 1f
+	mrs     x4, fpexc32_el2
+	str     x4, [x2, #CPU_SYSREG_OFFSET(FPEXC32_EL2)]
+1:
+	bl __save_fpsimd
+
+	ldr     x2, [x0, #VCPU_HOST_CONTEXT]
+	kern_hyp_va x2
+	bl __restore_fpsimd
+
+	pop	x4, lr
+	ret
+ENDPROC(__kvm_restore_host_vfp_state)
+
 __kvm_hyp_panic:
 	// Guess the context by looking@VTTBR:
 	// If zero, then we're already a host.
-- 
1.9.1

[RFT - PATCH v2 0/2] KVM/arm64: add fp/simd lazy switch support

[Christoffer Dall]

On Tue, Sep 22, 2015 at 04:34:01PM -0700, Mario Smarduch wrote:
> This is a 2nd itteration for arm64, v1 patches were posted by mistake from an 
> older branch which included several bugs. Hopefully didn't waste too much of 
> anyones time.
> 
> This patch series is a followup to the armv7 fp/simd lazy switch
> implementation, uses similar approach and depends on the series - see
> https://lists.cs.columbia.edu/pipermail/kvmarm/2015-September/016516.html
> 
> It's based on earlier arm64 fp/simd optimization work - see
> https://lists.cs.columbia.edu/pipermail/kvmarm/2015-July/015748.html
> 
> And subsequent fixes by Marc and Christoffer at KVM Forum hackathon to handle
> 32-bit guest on 64 bit host (and may require more here) - see
> https://lists.cs.columbia.edu/pipermail/kvmarm/2015-August/016128.html
> 
> This series has be tested with arm64 on arm64 with several FP applications 
> running on host and guest, with substantial decrease on number of 
> fp/simd context switches. From about 30% down to 2% with one guest running.
> 
> At this time I don't have arm32/arm64 working and hoping Christoffer and/or
> Marc (or anyone) can test 32-bit guest/64-bit host.
> 
Did you already have some test infrastructure/applications that I can
reuse for this purpose or do I have to write userspace software?

-Christoffer

[RFT - PATCH v2 0/2] KVM/arm64: add fp/simd lazy switch support

[Mario Smarduch]

Hi Christoffer,
   I just managed to boot qemu arm32 up on arm64 (last Fri - thanks for the tip
- there were few other issue to clean up), so let me retest it again. Also I
noticed some refactoring would help both 32 and 64 bit patches.

Yes I could provide a the user space tests as well.

Thanks-
- Mario

On 10/5/2015 8:45 AM, Christoffer Dall wrote:
> On Tue, Sep 22, 2015 at 04:34:01PM -0700, Mario Smarduch wrote:
>> This is a 2nd itteration for arm64, v1 patches were posted by mistake from an 
>> older branch which included several bugs. Hopefully didn't waste too much of 
>> anyones time.
>>
>> This patch series is a followup to the armv7 fp/simd lazy switch
>> implementation, uses similar approach and depends on the series - see
>> https://lists.cs.columbia.edu/pipermail/kvmarm/2015-September/016516.html
>>
>> It's based on earlier arm64 fp/simd optimization work - see
>> https://lists.cs.columbia.edu/pipermail/kvmarm/2015-July/015748.html
>>
>> And subsequent fixes by Marc and Christoffer at KVM Forum hackathon to handle
>> 32-bit guest on 64 bit host (and may require more here) - see
>> https://lists.cs.columbia.edu/pipermail/kvmarm/2015-August/016128.html
>>
>> This series has be tested with arm64 on arm64 with several FP applications 
>> running on host and guest, with substantial decrease on number of 
>> fp/simd context switches. From about 30% down to 2% with one guest running.
>>
>> At this time I don't have arm32/arm64 working and hoping Christoffer and/or
>> Marc (or anyone) can test 32-bit guest/64-bit host.
>>
> Did you already have some test infrastructure/applications that I can
> reuse for this purpose or do I have to write userspace software?
> 
> -Christoffer
> 

[RFT - PATCH v2 0/2] KVM/arm64: add fp/simd lazy switch support

[Christoffer Dall]

On Mon, Oct 05, 2015 at 09:14:57AM -0700, Mario Smarduch wrote:
> Hi Christoffer,
>    I just managed to boot qemu arm32 up on arm64 (last Fri - thanks for the tip
> - there were few other issue to clean up), so let me retest it again. Also I
> noticed some refactoring would help both 32 and 64 bit patches.
> 
> Yes I could provide a the user space tests as well.
> 
I'd like those regardless as I generally test my queue before pushing it
to next.

Thanks,
-Christoffer

[RFT - PATCH v2 0/2] KVM/arm64: add fp/simd lazy switch support

[Mario Smarduch]

Will do, I'll get them over to you.

-----Original Message-----
From: Christoffer Dall [mailto:christoffer.dall at linaro.org] 
Sent: Monday, October 05, 2015 10:26 AM
To: Mario Smarduch
Cc: kvmarm at lists.cs.columbia.edu; marc.zyngier at arm.com; kvm at vger.kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [RFT - PATCH v2 0/2] KVM/arm64: add fp/simd lazy switch support

On Mon, Oct 05, 2015 at 09:14:57AM -0700, Mario Smarduch wrote:
> Hi Christoffer,
>    I just managed to boot qemu arm32 up on arm64 (last Fri - thanks 
> for the tip
> - there were few other issue to clean up), so let me retest it again. 
> Also I noticed some refactoring would help both 32 and 64 bit patches.
> 
> Yes I could provide a the user space tests as well.
> 
I'd like those regardless as I generally test my queue before pushing it to next.

Thanks,
-Christoffer

[RFT - PATCH v2 0/2] KVM/arm64: add fp/simd lazy switch support

[Mario Smarduch]

Hi Christoffer, Marc -
  I just threw this test your way without any explanation.

The test loops, does fp arithmetic and checks the truncated result.
It could be a little more dynamic have an initial run to
get the sum to compare against while looping, different fp
hardware may come up with a different sum, but truncation is
to 5'th decimal point.

The rationale is that if there is any fp/simd corruption
one of these runs should fail. I think most likely scenario
for that is a world switch in midst of fp operation. I've
instrumented (basically add some tracing to vcpu_put()) and
validated vcpu_put gets called thousands of time (for v7,v8)
for an over night test running two guests/host crunching
fp operations.

Other then that not sure how to really catch any problems
with the patches applied. Obviously this is a huge issues, if this has
any problems. If you or Marc have any other ideas I'd be happy
to enhance the test.

Thanks,
  Mario

On 10/5/2015 8:45 AM, Christoffer Dall wrote:
> On Tue, Sep 22, 2015 at 04:34:01PM -0700, Mario Smarduch wrote:
>> This is a 2nd itteration for arm64, v1 patches were posted by mistake from an 
>> older branch which included several bugs. Hopefully didn't waste too much of 
>> anyones time.
>>
>> This patch series is a followup to the armv7 fp/simd lazy switch
>> implementation, uses similar approach and depends on the series - see
>> https://lists.cs.columbia.edu/pipermail/kvmarm/2015-September/016516.html
>>
>> It's based on earlier arm64 fp/simd optimization work - see
>> https://lists.cs.columbia.edu/pipermail/kvmarm/2015-July/015748.html
>>
>> And subsequent fixes by Marc and Christoffer at KVM Forum hackathon to handle
>> 32-bit guest on 64 bit host (and may require more here) - see
>> https://lists.cs.columbia.edu/pipermail/kvmarm/2015-August/016128.html
>>
>> This series has be tested with arm64 on arm64 with several FP applications 
>> running on host and guest, with substantial decrease on number of 
>> fp/simd context switches. From about 30% down to 2% with one guest running.
>>
>> At this time I don't have arm32/arm64 working and hoping Christoffer and/or
>> Marc (or anyone) can test 32-bit guest/64-bit host.
>>
> Did you already have some test infrastructure/applications that I can
> reuse for this purpose or do I have to write userspace software?
> 
> -Christoffer
> 

[RFT - PATCH v2 0/2] KVM/arm64: add fp/simd lazy switch support

[Christoffer Dall]

On Mon, Oct 12, 2015 at 09:29:23AM -0700, Mario Smarduch wrote:
> Hi Christoffer, Marc -
>   I just threw this test your way without any explanation.

I'm confused.  Did you send me something somewhere already?

> 
> The test loops, does fp arithmetic and checks the truncated result.
> It could be a little more dynamic have an initial run to
> get the sum to compare against while looping, different fp
> hardware may come up with a different sum, but truncation is
> to 5'th decimal point.
> 
> The rationale is that if there is any fp/simd corruption
> one of these runs should fail. I think most likely scenario
> for that is a world switch in midst of fp operation. I've
> instrumented (basically add some tracing to vcpu_put()) and
> validated vcpu_put gets called thousands of time (for v7,v8)
> for an over night test running two guests/host crunching
> fp operations.
> 
> Other then that not sure how to really catch any problems
> with the patches applied. Obviously this is a huge issues, if this has
> any problems. If you or Marc have any other ideas I'd be happy
> to enhance the test.

I think it's important to run two VMs at the same time, each with some
floating-point work, and then run some floating point on the host at the
same time.

You can make that even more interesting by doing 32-bit guests at the
same time as well.

I believe Marc was running Panranoia
(http://www.netlib.org/paranoia/paranoia.c) to test the last lazy
series.

Thanks,
-Christoffer

[RFT - PATCH v2 0/2] KVM/arm64: add fp/simd lazy switch support

[Mario Smarduch]

On 10/18/2015 2:07 PM, Christoffer Dall wrote:
> On Mon, Oct 12, 2015 at 09:29:23AM -0700, Mario Smarduch wrote:
>> Hi Christoffer, Marc -
>>   I just threw this test your way without any explanation.
> 
> I'm confused.  Did you send me something somewhere already?
Yes in the last patchset

https://lists.cs.columbia.edu/pipermail/kvmarm/2015-October/016698.html

I included a simple test I put together.

> 
>>
>> The test loops, does fp arithmetic and checks the truncated result.
>> It could be a little more dynamic have an initial run to
>> get the sum to compare against while looping, different fp
>> hardware may come up with a different sum, but truncation is
>> to 5'th decimal point.
>>
>> The rationale is that if there is any fp/simd corruption
>> one of these runs should fail. I think most likely scenario
>> for that is a world switch in midst of fp operation. I've
>> instrumented (basically add some tracing to vcpu_put()) and
>> validated vcpu_put gets called thousands of time (for v7,v8)
>> for an over night test running two guests/host crunching
>> fp operations.
>>
>> Other then that not sure how to really catch any problems
>> with the patches applied. Obviously this is a huge issues, if this has
>> any problems. If you or Marc have any other ideas I'd be happy
>> to enhance the test.
> 
> I think it's important to run two VMs at the same time, each with some
> floating-point work, and then run some floating point on the host at the
> same time.
> 
> You can make that even more interesting by doing 32-bit guests at the
> same time as well.

Yes that's the test combination I've been running.
> 
> I believe Marc was running Panranoia
> (http://www.netlib.org/paranoia/paranoia.c) to test the last lazy
> series.

I'll try this test and run it for several days, see if anything shows up.

Thanks.
> 
> Thanks,
> -Christoffer
> 

[RFT - PATCH v2 0/2] KVM/arm64: add fp/simd lazy switch support

[Christoffer Dall]

On Mon, Oct 19, 2015 at 03:06:59PM -0700, Mario Smarduch wrote:
> 
> 
> On 10/18/2015 2:07 PM, Christoffer Dall wrote:
> > On Mon, Oct 12, 2015 at 09:29:23AM -0700, Mario Smarduch wrote:
> >> Hi Christoffer, Marc -
> >>   I just threw this test your way without any explanation.
> > 
> > I'm confused.  Did you send me something somewhere already?
> Yes in the last patchset
> 
> https://lists.cs.columbia.edu/pipermail/kvmarm/2015-October/016698.html
> 
> I included a simple test I put together.
> 

Sorry, I missed that change in the cover letter.

> > 
> >>
> >> The test loops, does fp arithmetic and checks the truncated result.
> >> It could be a little more dynamic have an initial run to
> >> get the sum to compare against while looping, different fp
> >> hardware may come up with a different sum, but truncation is
> >> to 5'th decimal point.
> >>
> >> The rationale is that if there is any fp/simd corruption
> >> one of these runs should fail. I think most likely scenario
> >> for that is a world switch in midst of fp operation. I've
> >> instrumented (basically add some tracing to vcpu_put()) and
> >> validated vcpu_put gets called thousands of time (for v7,v8)
> >> for an over night test running two guests/host crunching
> >> fp operations.
> >>
> >> Other then that not sure how to really catch any problems
> >> with the patches applied. Obviously this is a huge issues, if this has
> >> any problems. If you or Marc have any other ideas I'd be happy
> >> to enhance the test.
> > 
> > I think it's important to run two VMs at the same time, each with some
> > floating-point work, and then run some floating point on the host at the
> > same time.
> > 
> > You can make that even more interesting by doing 32-bit guests at the
> > same time as well.
> 
> Yes that's the test combination I've been running.

ok, cool, then I trust these patches.

> > 
> > I believe Marc was running Panranoia
> > (http://www.netlib.org/paranoia/paranoia.c) to test the last lazy
> > series.
> 
> I'll try this test and run it for several days, see if anything shows up.
> 

I actually don't know what it does, i.e. if it just uses the FP hardware
or if it actually checks the results produced.

Several days may be unnecessary, but if your machine has nothing else to
do, then why not.

Thanks,
-Christoffer