Thread (83 messages) 83 messages, 7 authors, 2016-02-03

[PATCH v2 05/21] arm64: KVM: VHE: Turn VTCR_EL2 setup into a reusable macro

From: Christoffer Dall <hidden>
Date: 2016-02-01 15:37:51
Also in: kvm, kvmarm, lkml

On Mon, Feb 01, 2016 at 02:21:57PM +0000, Marc Zyngier wrote:
On 01/02/16 13:13, Christoffer Dall wrote:
quoted
On Mon, Jan 25, 2016 at 03:53:39PM +0000, Marc Zyngier wrote:
quoted
On a VHE-capable system, there is no point in setting VTCR_EL2
at KVM init time. We can perfectly set it up when the kernel
boots, removing the need for a more complicated configuration.
what's the complicated configuration which is avoided?
With VHE, there is no hyp-init at all, so what we avoid is a weird init
sequence where we have to execute part of this hyp-init, but not all of it.
quoted
quoted
In order to allow this, turn VTCR_EL2 setup into a macro that
we'll be able to reuse at boot time.

Signed-off-by: Marc Zyngier <redacted>
---
 arch/arm64/include/asm/kvm_mmu.h | 23 +++++++++++++++++++++++
 arch/arm64/kvm/hyp-init.S        | 18 +-----------------
 2 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 7364339..d3e6d7b 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -56,6 +56,29 @@
 
 #ifdef __ASSEMBLY__
 
+#include <asm/kvm_arm.h>
+
+.macro setup_vtcr tmp1, tmp2
+	mov	\tmp1, #(VTCR_EL2_FLAGS & 0xffff)
+	movk	\tmp1, #(VTCR_EL2_FLAGS >> 16), lsl #16
+	/*
+	 * Read the PARange bits from ID_AA64MMFR0_EL1 and set the PS bits in
+	 * VTCR_EL2.
+	 */
+	mrs	\tmp2, id_aa64mmfr0_el1
+	bfi	\tmp1, \tmp2, #16, #3
+	/*
+	 * Read the VMIDBits bits from ID_AA64MMFR1_EL1 and set the VS bit in
+	 * VTCR_EL2.
+	 */
+	mrs	\tmp2, ID_AA64MMFR1_EL1
+	ubfx	\tmp2, \tmp2, #5, #1
+	lsl	\tmp2, \tmp2, #VTCR_EL2_VS
+	orr	\tmp1, \tmp1, \tmp2
+
+	msr	vtcr_el2, \tmp1
+	isb
+.endm
this feels like an awful lot of code in a header file.
interrupt_head.S respectfully disagrees with you ;-).
quoted
Is it crazy to imagine wanting to have different T0SZ for different VMs
in the future?  In that case, the T0SZ stuff should stay in KVM...
That's a rather compelling argument indeed. I'll see if I can turn the
thing around in a slightly nicer way. How about moving it out of
hyp-init.S altogether, and into C code?
That sounds better to me.

Thanks,
-Christoffer
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help