KVM/ARM Implementation

Add a method (hyp_idmap_setup) to populate a hyp pgd with an identity mapping of the code contained in the .hyp.idmap.text section.

Offer a method to drop this identity mapping through hyp_idmap_teardown.

Make all the above depend on CONFIG_ARM_VIRT_EXT and CONFIG_ARM_LPAE.

Cc Will Deacon <[email protected]>

Reviewed-by Marcelo Tosatti <[email protected]>

Signed-off-by Marc Zyngier <[email protected]>

Signed-off-by Christoffer Dall <[email protected]>

---
 arch/arm/include/asm/idmap.h                |    1 +
 arch/arm/include/asm/pgtable-3level-hwdef.h |    1 +
 arch/arm/kernel/vmlinux.lds.S               |    6 +++
 arch/arm/mm/idmap.c                         |   54 ++++++++++++++++++++++-----
 4 files changed, 50 insertions(+), 12 deletions(-)

arch/arm/include/asm/idmap.h +1 -0

index bf863ed..1a66f907 100644
@@ -8,6 +8,7 @@
 #define __idmap __section(.idmap.text) noinline notrace
 
 extern pgd_t *idmap_pgd;
+extern pgd_t *hyp_pgd;
 
 void setup_mm_for_reboot(void);
 

arch/arm/include/asm/pgtable-3level-hwdef.h +1 -0

index d795282..a2d404e 100644
@@ -44,6 +44,7 @@
 #define PMD_SECT_XN		(_AT(pmdval_t, 1) << 54)
 #define PMD_SECT_AP_WRITE	(_AT(pmdval_t, 0))
 #define PMD_SECT_AP_READ	(_AT(pmdval_t, 0))
+#define PMD_SECT_AP1		(_AT(pmdval_t, 1) << 6)
 #define PMD_SECT_TEX(x)		(_AT(pmdval_t, 0))
 
 /*

arch/arm/kernel/vmlinux.lds.S +5 -1

index 11c1785..b571484 100644
@@ -19,7 +19,11 @@
 	ALIGN_FUNCTION();						\
 	VMLINUX_SYMBOL(__idmap_text_start) = .;				\
 	*(.idmap.text)							\
-	VMLINUX_SYMBOL(__idmap_text_end) = .;
+	VMLINUX_SYMBOL(__idmap_text_end) = .;				\
+	ALIGN_FUNCTION();						\
+	VMLINUX_SYMBOL(__hyp_idmap_text_start) = .;			\
+	*(.hyp.idmap.text)						\
+	VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;
 
 #ifdef CONFIG_HOTPLUG_CPU
 #define ARM_CPU_DISCARD(x)

arch/arm/mm/idmap.c +3 -0

index 99db769..d9213a5 100644
@@ -1,4 +1,6 @@
+#include <linux/module.h>
 #include <linux/kernel.h>
+#include <linux/slab.h>
 
 #include <asm/cputype.h>
 #include <asm/idmap.h>

@@ -6,6 +8,7 @@
 #include <asm/pgtable.h>
 #include <asm/sections.h>
 #include <asm/system_info.h>
+#include <asm/virt.h>
 
 pgd_t *idmap_pgd;
 

@@ -59,11 +62,20 @@ static void idmap_add_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
 	} while (pud++, addr = next, addr != end);
 }
 

arch/arm/mm/idmap.c +33 -10

+
+	pr_info("Setting up static %sidentity map for 0x%llx - 0x%llx\n",
+		prot ? "HYP " : "",
+		(long long)addr, (long long)end);
+	prot |= PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_AF;
 
-	prot = PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_AF;
 	if (cpu_architecture() <= CPU_ARCH_ARMv5TEJ && !cpu_is_xscale())
 		prot |= PMD_BIT4;
 

@@ -74,28 +86,48 @@ static void identity_mapping_add(pgd_t *pgd, unsigned long addr, unsigned long e
 	} while (pgd++, addr = next, addr != end);
 }
 
+#ifdef CONFIG_ARM_VIRT_EXT
+pgd_t *hyp_pgd;
+
+extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
+
+static int __init init_static_idmap_hyp(void)
+{
+	hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
+	if (!hyp_pgd)
+		return -ENOMEM;
+
+	identity_mapping_add(hyp_pgd, __hyp_idmap_text_start,
+			     __hyp_idmap_text_end, PMD_SECT_AP1);
+
+	return 0;
+}
+#else
+static int __init init_static_idmap_hyp(void)
+{
+	return 0;
+}
+#endif
+
 extern char  __idmap_text_start[], __idmap_text_end[];
 
 static int __init init_static_idmap(void)
 {
-	phys_addr_t idmap_start, idmap_end;
+	int ret;
 
 	idmap_pgd = pgd_alloc(&init_mm);
 	if (!idmap_pgd)
 		return -ENOMEM;
 
-	/* Add an identity mapping for the physical address of the section. */
-	idmap_start = virt_to_phys((void *)__idmap_text_start);
-	idmap_end = virt_to_phys((void *)__idmap_text_end);
+	identity_mapping_add(idmap_pgd, __idmap_text_start,
+			     __idmap_text_end, 0);
 
-	pr_info("Setting up static identity map for 0x%llx - 0x%llx\n",
-		(long long)idmap_start, (long long)idmap_end);
-	identity_mapping_add(idmap_pgd, idmap_start, idmap_end);
+	ret = init_static_idmap_hyp();
 
 	/* Flush L1 for the hardware to see this page table content */
 	flush_cache_louis();
 
-	return 0;
+	return ret;
 }
 early_initcall(init_static_idmap);
 
 
--

To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 19 lines · Christoffer Dall

Add a method (hyp_idmap_setup) to populate a hyp pgd with an identity mapping of the code contained in the .hyp.idmap.text section.

Offer a method to drop this identity mapping through hyp_idmap_teardown.

Make all the above depend on CONFIG_ARM_VIRT_EXT and CONFIG_ARM_LPAE.

Cc Will Deacon <[email protected]>

Reviewed-by Marcelo Tosatti <[email protected]>

Signed-off-by Marc Zyngier <[email protected]>

Signed-off-by Christoffer Dall <[email protected]>

---
 arch/arm/include/asm/idmap.h                |    1 +
 arch/arm/include/asm/pgtable-3level-hwdef.h |    1 +
 arch/arm/kernel/vmlinux.lds.S               |    6 +++
 arch/arm/mm/idmap.c                         |   54 ++++++++++++++++++++++-----
 4 files changed, 50 insertions(+), 12 deletions(-)

Quoted 6 lines

arch/arm/mm/idmap.c +3 -2

-static void identity_mapping_add(pgd_t *pgd, unsigned long addr, unsigned long end)
+static void identity_mapping_add(pgd_t *pgd, const char *text_start,
+				 const char *text_end, unsigned long prot)
 {
-	unsigned long prot, next;
+	unsigned long addr, end;

arch/arm/mm/idmap.c static void idmap_add_pud(pgd_t *pgd, unsigned long addr, unsigned long end, · line 72

Quoted 4 lines

arch/arm/mm/idmap.c +4 -0

+	unsigned long next;
+
+	addr = virt_to_phys(text_start);
+	end = virt_to_phys(text_end);

How does this work with phys addresses greater than 32bit (with LPAE)? This was the same before the patch too, but I am still curious. Since __virt_to_phys() returns unsigned long kernel cannot be put in high memory, right?

Quoted 20 lines · Gleb Natapov

Quoted 19 lines · Christoffer Dall

Add a method (hyp_idmap_setup) to populate a hyp pgd with an identity mapping of the code contained in the .hyp.idmap.text section.

Offer a method to drop this identity mapping through hyp_idmap_teardown.

Make all the above depend on CONFIG_ARM_VIRT_EXT and CONFIG_ARM_LPAE.

Cc Will Deacon <[email protected]>

Reviewed-by Marcelo Tosatti <[email protected]>

Signed-off-by Marc Zyngier <[email protected]>

Signed-off-by Christoffer Dall <[email protected]>

---
 arch/arm/include/asm/idmap.h                |    1 +
 arch/arm/include/asm/pgtable-3level-hwdef.h |    1 +
 arch/arm/kernel/vmlinux.lds.S               |    6 +++
 arch/arm/mm/idmap.c                         |   54 ++++++++++++++++++++++-----
 4 files changed, 50 insertions(+), 12 deletions(-)

[...]

Quoted 6 lines

Quoted 6 lines

arch/arm/mm/idmap.c +3 -2

-static void identity_mapping_add(pgd_t *pgd, unsigned long addr, unsigned long end)
+static void identity_mapping_add(pgd_t *pgd, const char *text_start,
+				 const char *text_end, unsigned long prot)
 {
-	unsigned long prot, next;
+	unsigned long addr, end;

Quoted 8 lines

arch/arm/mm/idmap.c static void idmap_add_pud(pgd_t *pgd, unsigned long addr, unsigned long end, · line 72

Quoted 4 lines

arch/arm/mm/idmap.c +4 -0

+	unsigned long next;
+
+	addr = virt_to_phys(text_start);
+	end = virt_to_phys(text_end);

How does this work with phys addresses greater than 32bit (with LPAE)? This was the same before the patch too, but I am still curious. Since __virt_to_phys() returns unsigned long kernel cannot be put in high memory, right?

Well, AArch32 (arch/arm/) only supports 32-bit virtual addresses by virtue of the fact that our registers are only 32 bits wide, so we can't identity-map physical addresses above the 4GB boundary.

You may want to look at the keystone patches from TI for insight about kernels at high (>32-bit) addresses, although I've not seen any activity around that for some time now (which is a pity, because the code-patching stuff was in a good shape).

Will

Ah, of course. This is ident map so by definition it cannot map phys addresses above 4G. And since __virt_to_phys() suppose to work only on ident map it's OK to returns unsigned long.

Review

Quoted 3 lines · Christoffer Dall

(quoted diff) +3 -0

+     pr_info("Setting up static %sidentity map for 0x%llx - 0x%llx\n",
+             prot ? "HYP " : "",
+             (long long)addr, (long long)end);

There's no point using 0x%llx and casting to 64-bit longs if the arguments are always going to be 32-bit.

Targets KVM support for Cortex A-15 processors.

Contains all the framework components, make files, header files, some tracing functionality, and basic user space API.

Only supported core is Cortex-A15 for now.

Most functionality is in arch/arm/kvm/* or arch/arm/include/asm/kvm_*.h.

Reviewed-by Marcelo Tosatti <[email protected]>

Signed-off-by Rusty Russell <[email protected]>

Signed-off-by Marc Zyngier <[email protected]>

Signed-off-by Christoffer Dall <[email protected]>

---
 Documentation/virtual/kvm/api.txt  |   57 +++++-
 arch/arm/Kconfig                   |    2
 arch/arm/Makefile                  |    1
 arch/arm/include/asm/kvm_arm.h     |   24 ++
 arch/arm/include/asm/kvm_asm.h     |   58 ++++++
 arch/arm/include/asm/kvm_coproc.h  |   24 ++
 arch/arm/include/asm/kvm_emulate.h |   50 +++++
 arch/arm/include/asm/kvm_host.h    |  114 ++++++++++++
 arch/arm/include/uapi/asm/kvm.h    |  106 +++++++++++

arch/arm/include/uapi/asm/kvm.h new file +13 -0

new file mode 100644
index 0000000..c6298b1
@@ -0,0 +1,106 @@
+/*
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Author: Christoffer Dall <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *

Quoted 23 lines · Christoffer Dall

Targets KVM support for Cortex A-15 processors.

Contains all the framework components, make files, header files, some tracing functionality, and basic user space API.

Only supported core is Cortex-A15 for now.

Most functionality is in arch/arm/kvm/* or arch/arm/include/asm/kvm_*.h.

Reviewed-by Marcelo Tosatti <[email protected]>

Signed-off-by Rusty Russell <[email protected]>

Signed-off-by Marc Zyngier <[email protected]>

Signed-off-by Christoffer Dall <[email protected]>

---
 Documentation/virtual/kvm/api.txt  |   57 +++++-
 arch/arm/Kconfig                   |    2
 arch/arm/Makefile                  |    1
 arch/arm/include/asm/kvm_arm.h     |   24 ++
 arch/arm/include/asm/kvm_asm.h     |   58 ++++++
 arch/arm/include/asm/kvm_coproc.h  |   24 ++
 arch/arm/include/asm/kvm_emulate.h |   50 +++++
 arch/arm/include/asm/kvm_host.h    |  114 ++++++++++++
 arch/arm/include/uapi/asm/kvm.h    |  106 +++++++++++

[...]

Quoted 19 lines

arch/arm/include/uapi/asm/kvm.h new file +13 -0

new file mode 100644
index 0000000..c6298b1
@@ -0,0 +1,106 @@
+/*
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Author: Christoffer Dall <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *

arch/arm/include/uapi/asm/kvm.h line 23

Quoted 10 lines

arch/arm/include/uapi/asm/kvm.h new file +10 -0

+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ */
+
+#ifndef __ARM_KVM_H__
+#define __ARM_KVM_H__
+
+#include <asm/types.h>
+#include <asm/ptrace.h>

I think you want linux/types.h, as asm/types.h isn't exported from what I can tell. make headers_check screams about it too:

/home/will/sources/linux/linux/usr/include/asm/kvm.h:22: include of <linux/types.h> is preferred over <asm/types.h> /home/will/sources/linux/linux/usr/include/asm/kvm.h:57: found __[us]{8,16,32,64} type without #include <linux/types.h>

Review

Quoted 3 lines · Christoffer Dall

(quoted diff) +3 -0

+     /* -ENOENT for unknown features, -EINVAL for invalid combinations. */
+     for (i = 0; i < sizeof(init->features)*8; i++) {
+             if (init->features[i / 32] & (1 << (i % 32))) {

Isn't this an open-coded version of test_bit() ?

Quoted 6 lines · Russell King - ARM Linux

Review

Quoted 3 lines · Christoffer Dall

(quoted diff) +3 -0

+     /* -ENOENT for unknown features, -EINVAL for invalid combinations. */
+     for (i = 0; i < sizeof(init->features)*8; i++) {
+             if (init->features[i / 32] & (1 << (i % 32))) {

Isn't this an open-coded version of test_bit() ?

indeed, nicely spotted:

Quoted 7 lines · Christoffer Dall

Quoted 5 lines · Russell King - ARM Linux

Quoted 3 lines · Christoffer Dall

(quoted diff) +3 -0

+     /* -ENOENT for unknown features, -EINVAL for invalid combinations. */
+     for (i = 0; i < sizeof(init->features)*8; i++) {
+             if (init->features[i / 32] & (1 << (i % 32))) {

Quoted 3 lines

Quoted 1 line

Isn't this an open-coded version of test_bit() ?

indeed, nicely spotted:

BTW, I wrote it that was out of excessive paranoia: it's a userspace API, and test_bit() won't be right on 64 bit BE systems.

Quoted 11 lines · Rusty Russell

Quoted 9 lines · Christoffer Dall

Quoted 6 lines · Russell King - ARM Linux

Review

Quoted 3 lines · Christoffer Dall

(quoted diff) +3 -0

+     /* -ENOENT for unknown features, -EINVAL for invalid combinations. */
+     for (i = 0; i < sizeof(init->features)*8; i++) {
+             if (init->features[i / 32] & (1 << (i % 32))) {

Isn't this an open-coded version of test_bit() ?

Quoted 4 lines

Quoted 1 line

indeed, nicely spotted:

BTW, I wrote it that was out of excessive paranoia: it's a userspace API, and test_bit() won't be right on 64 bit BE systems.

So why is this a concern for 32-bit systems (which are, by definition, only in arch/arm) ?

Documentation/virtual/kvm/api.txt +2 -2

index a4df553..4237c27 100644
@@ -293,7 +293,7 @@ kvm_run' (see below).
 4.11 KVM_GET_REGS
 
 Capability: basic
-Architectures: all
+Architectures: all except ARM
 Type: vcpu ioctl
 Parameters: struct kvm_regs (out)
 Returns: 0 on success, -1 on error

@@ -314,7 +314,7 @@ struct kvm_regs {
 4.12 KVM_SET_REGS
 
 Capability: basic
-Architectures: all
+Architectures: all except ARM
 Type: vcpu ioctl
 Parameters: struct kvm_regs (in)
 Returns: 0 on success, -1 on error

Documentation/virtual/kvm/api.txt +17 -2

 Capability: KVM_CAP_IRQCHIP
-Architectures: x86, ia64
+Architectures: x86, ia64, ARM
 Type: vm ioctl
 Parameters: none
 Returns: 0 on success, -1 on error

@@ -608,7 +608,8 @@ Returns: 0 on success, -1 on error
 Creates an interrupt controller model in the kernel.  On x86, creates a virtual
 ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a
 local APIC.  IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23
-only go to the IOAPIC.  On ia64, a IOSAPIC is created.
+only go to the IOAPIC.  On ia64, a IOSAPIC is created. On ARM, a GIC is
+created.
 
 
 4.25 KVM_IRQ_LINE

@@ -1775,6 +1776,14 @@ registers, find a list below:
   PPC   | KVM_REG_PPC_VPA_DTL   | 128
   PPC   | KVM_REG_PPC_EPCR	| 32
 
+ARM registers are mapped using the lower 32 bits.  The upper 16 of that
+is the register group type, or coprocessor number:
+
+ARM core registers have the following id bit patterns:
+  0x4002 0000 0010 <index into the kvm_regs struct:16>
+
+
+
 4.69 KVM_GET_ONE_REG
 
 Capability: KVM_CAP_ONE_REG

@@ -2127,6 +2136,46 @@ written, then `n_invalid' invalid entries, invalidating any previously
 valid entries found.
 
 
+4.77 KVM_ARM_VCPU_INIT
+
+Capability: basic
+Architectures: arm
+Type: vcpu ioctl
+Parameters: struct struct kvm_vcpu_init (in)

Documentation/virtual/kvm/api.txt +12 -0

+
+
+4.78 KVM_GET_REG_LIST
+
+Capability: basic
+Architectures: arm
+Type: vcpu ioctl
+Parameters: struct kvm_reg_list (in/out)
+Returns: 0 on success; -1 on error
+Errors:
+ ?E2BIG: ????the reg index list is too big to fit in the array specified by
+ ????????????the user (the number required will be written into n).

A couple of general question about ABI. If they were already answered just refer me to the previous discussion.

Quoted 16 lines · Christoffer Dall

Documentation/virtual/kvm/api.txt +1 -1

index a4df553..4237c27 100644
@@ -293,7 +293,7 @@ kvm_run' (see below).
 4.11 KVM_GET_REGS
 
 Capability: basic
-Architectures: all
+Architectures: all except ARM
 Type: vcpu ioctl
 Parameters: struct kvm_regs (out)
 Returns: 0 on success, -1 on error

@@ -314,7 +314,7 @@ struct kvm_regs {
 4.12 KVM_SET_REGS
 

Documentation/virtual/kvm/api.txt struct kvm_fpu { · line 600

Quoted 8 lines

Documentation/virtual/kvm/api.txt +1 -1

 Capability: basic
-Architectures: all
+Architectures: all except ARM
 Type: vcpu ioctl
 Parameters: struct kvm_regs (in)
 Returns: 0 on success, -1 on error

@@ -600,7 +600,7 @@ struct kvm_fpu {
 4.24 KVM_CREATE_IRQCHIP

Why KVM_GET_REGS/KVM_SET_REGS are not usable for arm?

Quoted 45 lines

Documentation/virtual/kvm/api.txt +20 -2

 Capability: KVM_CAP_IRQCHIP
-Architectures: x86, ia64
+Architectures: x86, ia64, ARM
 Type: vm ioctl
 Parameters: none
 Returns: 0 on success, -1 on error

@@ -608,7 +608,8 @@ Returns: 0 on success, -1 on error
 Creates an interrupt controller model in the kernel.  On x86, creates a virtual
 ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a
 local APIC.  IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23
-only go to the IOAPIC.  On ia64, a IOSAPIC is created.
+only go to the IOAPIC.  On ia64, a IOSAPIC is created. On ARM, a GIC is
+created.
 
 
 4.25 KVM_IRQ_LINE

@@ -1775,6 +1776,14 @@ registers, find a list below:
   PPC   | KVM_REG_PPC_VPA_DTL   | 128
   PPC   | KVM_REG_PPC_EPCR   | 32
 
+ARM registers are mapped using the lower 32 bits.  The upper 16 of that
+is the register group type, or coprocessor number:
+
+ARM core registers have the following id bit patterns:
+  0x4002 0000 0010 <index into the kvm_regs struct:16>
+
+
+
 4.69 KVM_GET_ONE_REG
 
 Capability: KVM_CAP_ONE_REG

@@ -2127,6 +2136,46 @@ written, then `n_invalid' invalid entries, invalidating any previously
 valid entries found.
 
 
+4.77 KVM_ARM_VCPU_INIT
+
+Capability: basic
+Architectures: arm
+Type: vcpu ioctl
+Parameters: struct struct kvm_vcpu_init (in)
+Returns: 0 on success; -1 on error
+Errors:
+  EINVAL:    the target is unknown, or the combination of features is invalid.

Documentation/virtual/kvm/api.txt written, then `n_invalid' invalid entries, invalidating any previously · line 2154

Quoted 7 lines

Documentation/virtual/kvm/api.txt +7 -0

+  ENOENT:    a features bit specified is unknown.
+
+This tells KVM what type of CPU to present to the guest, and what
+optional features it should have.  This will cause a reset of the cpu
+registers to their initial values.  If this is not called, KVM_RUN will
+return ENOEXEC for that vcpu.
+

Can different vcpus of the same VM be of different type?

Documentation/virtual/kvm/api.txt written, then `n_invalid' invalid entries, invalidating any previously · line 2156

Quoted 2 lines

Documentation/virtual/kvm/api.txt +2 -0

+Note that because some registers reflect machine topology, all vcpus
+should be created before this ioctl is invoked.

How cpu hot plug suppose to work?

Quoted 15 lines

Documentation/virtual/kvm/api.txt +15 -0

+
+
+4.78 KVM_GET_REG_LIST
+
+Capability: basic
+Architectures: arm
+Type: vcpu ioctl
+Parameters: struct kvm_reg_list (in/out)
+Returns: 0 on success; -1 on error
+Errors:
+  E2BIG:     the reg index list is too big to fit in the array specified by
+             the user (the number required will be written into n).
+
+struct kvm_reg_list {
+     __u64 n; /* number of registers in reg[] */

Documentation/virtual/kvm/api.txt written, then `n_invalid' invalid entries, invalidating any previously · line 2178

Quoted 7 lines

Documentation/virtual/kvm/api.txt +7 -0

+     __u64 reg[0];
+};
+
+This ioctl returns the guest registers that are supported for the
+KVM_GET_ONE_REG/KVM_SET_ONE_REG calls.
+
+

Doesn't userspace know what registers are supported by each CPU type?

Quoted 20 lines · Gleb Natapov

A couple of general question about ABI. If they were already answered just refer me to the previous discussion.

Quoted 16 lines · Christoffer Dall

Documentation/virtual/kvm/api.txt +1 -1

index a4df553..4237c27 100644
@@ -293,7 +293,7 @@ kvm_run' (see below).
 4.11 KVM_GET_REGS
 
 Capability: basic
-Architectures: all
+Architectures: all except ARM
 Type: vcpu ioctl
 Parameters: struct kvm_regs (out)
 Returns: 0 on success, -1 on error

@@ -314,7 +314,7 @@ struct kvm_regs {
 4.12 KVM_SET_REGS
 

Quoted 10 lines

Documentation/virtual/kvm/api.txt struct kvm_fpu { · line 600

Quoted 8 lines

Documentation/virtual/kvm/api.txt +1 -1

 Capability: basic
-Architectures: all
+Architectures: all except ARM
 Type: vcpu ioctl
 Parameters: struct kvm_regs (in)
 Returns: 0 on success, -1 on error

@@ -600,7 +600,7 @@ struct kvm_fpu {
 4.24 KVM_CREATE_IRQCHIP

Why KVM_GET_REGS/KVM_SET_REGS are not usable for arm?

We use the ONE_REG API instead and we don't want to support two separate APIs to user space.

Quoted 45 lines

Quoted 45 lines

Documentation/virtual/kvm/api.txt +20 -2

 Capability: KVM_CAP_IRQCHIP
-Architectures: x86, ia64
+Architectures: x86, ia64, ARM
 Type: vm ioctl
 Parameters: none
 Returns: 0 on success, -1 on error

@@ -608,7 +608,8 @@ Returns: 0 on success, -1 on error
 Creates an interrupt controller model in the kernel.  On x86, creates a virtual
 ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a
 local APIC.  IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23
-only go to the IOAPIC.  On ia64, a IOSAPIC is created.
+only go to the IOAPIC.  On ia64, a IOSAPIC is created. On ARM, a GIC is
+created.
 
 
 4.25 KVM_IRQ_LINE

@@ -1775,6 +1776,14 @@ registers, find a list below:
   PPC   | KVM_REG_PPC_VPA_DTL   | 128
   PPC   | KVM_REG_PPC_EPCR   | 32
 
+ARM registers are mapped using the lower 32 bits.  The upper 16 of that
+is the register group type, or coprocessor number:
+
+ARM core registers have the following id bit patterns:
+  0x4002 0000 0010 <index into the kvm_regs struct:16>
+
+
+
 4.69 KVM_GET_ONE_REG
 
 Capability: KVM_CAP_ONE_REG

@@ -2127,6 +2136,46 @@ written, then `n_invalid' invalid entries, invalidating any previously
 valid entries found.
 
 
+4.77 KVM_ARM_VCPU_INIT
+
+Capability: basic
+Architectures: arm
+Type: vcpu ioctl
+Parameters: struct struct kvm_vcpu_init (in)
+Returns: 0 on success; -1 on error
+Errors:
+  EINVAL:    the target is unknown, or the combination of features is invalid.

Quoted 9 lines

Documentation/virtual/kvm/api.txt written, then `n_invalid' invalid entries, invalidating any previously · line 2154

Quoted 7 lines

Documentation/virtual/kvm/api.txt +7 -0

+  ENOENT:    a features bit specified is unknown.
+
+This tells KVM what type of CPU to present to the guest, and what
+optional features it should have.  This will cause a reset of the cpu
+registers to their initial values.  If this is not called, KVM_RUN will
+return ENOEXEC for that vcpu.
+

Can different vcpus of the same VM be of different type?

In the future yes. For example, if we ever want to virtualize a Big.Little system.

Quoted 4 lines

Documentation/virtual/kvm/api.txt written, then `n_invalid' invalid entries, invalidating any previously · line 2156

Quoted 2 lines

Documentation/virtual/kvm/api.txt +2 -0

+Note that because some registers reflect machine topology, all vcpus
+should be created before this ioctl is invoked.

How cpu hot plug suppose to work?

Those CPUs would be added from the beginning, but not powered on, and would be powered on later on, I suppose. See
https://lists.cs.columbia.edu/pipermail/kvmarm/2013-January/004617.html.

Quoted 16 lines

Quoted 16 lines

Documentation/virtual/kvm/api.txt +15 -0

+
+
+4.78 KVM_GET_REG_LIST
+
+Capability: basic
+Architectures: arm
+Type: vcpu ioctl
+Parameters: struct kvm_reg_list (in/out)
+Returns: 0 on success; -1 on error
+Errors:
+  E2BIG:     the reg index list is too big to fit in the array specified by
+             the user (the number required will be written into n).
+
+struct kvm_reg_list {
+     __u64 n; /* number of registers in reg[] */

Quoted 9 lines

Documentation/virtual/kvm/api.txt written, then `n_invalid' invalid entries, invalidating any previously · line 2178

Quoted 7 lines

Documentation/virtual/kvm/api.txt +7 -0

+     __u64 reg[0];
+};
+
+This ioctl returns the guest registers that are supported for the
+KVM_GET_ONE_REG/KVM_SET_ONE_REG calls.
+
+

Doesn't userspace know what registers are supported by each CPU type?

It would know about core registers, but there is a huge space of co-processors, and we don't emulate all of them or support getting/setting all of them yet. Surely this is something that will change over time and we want user space to be able to discover the available registers for backwards compatibility, migration, etc.

-Christoffer

Quoted 32 lines · Christoffer Dall

Quoted 30 lines · Gleb Natapov

A couple of general question about ABI. If they were already answered just refer me to the previous discussion.

Quoted 23 lines · Christoffer Dall

Documentation/virtual/kvm/api.txt +0 -0

index a4df553..4237c27 100644
@@ -293,7 +293,7 @@ kvm_run' (see below).

4.11 KVM_GET_REGS

Capability: basic

Documentation/virtual/kvm/api.txt +1 -1

-Architectures: all
+Architectures: all except ARM

Type: vcpu ioctl
Parameters: struct kvm_regs (out)
Returns: 0 on success, -1 on error

Documentation/virtual/kvm/api.txt +0 -0

@@ -314,7 +314,7 @@ struct kvm_regs {

4.12 KVM_SET_REGS

Capability: basic

Documentation/virtual/kvm/api.txt +1 -1

-Architectures: all
+Architectures: all except ARM

Type: vcpu ioctl
Parameters: struct kvm_regs (in)
Returns: 0 on success, -1 on error

Documentation/virtual/kvm/api.txt +0 -0

@@ -600,7 +600,7 @@ struct kvm_fpu {

Quoted 1 line

4.24 KVM_CREATE_IRQCHIP

Why KVM_GET_REGS/KVM_SET_REGS are not usable for arm?

Quoted 3 lines

We use the ONE_REG API instead and we don't want to support two separate APIs to user space.

I suppose fetching all registers is not anywhere on a fast path in userspace :)

Quoted 33 lines · Gleb Natapov

Quoted 32 lines · Christoffer Dall

Quoted 30 lines · Gleb Natapov

A couple of general question about ABI. If they were already answered just refer me to the previous discussion.

Quoted 23 lines · Christoffer Dall

Documentation/virtual/kvm/api.txt +0 -0

index a4df553..4237c27 100644
@@ -293,7 +293,7 @@ kvm_run' (see below).

4.11 KVM_GET_REGS

Capability: basic

Documentation/virtual/kvm/api.txt +1 -1

-Architectures: all
+Architectures: all except ARM

Type: vcpu ioctl
Parameters: struct kvm_regs (out)
Returns: 0 on success, -1 on error

Documentation/virtual/kvm/api.txt +0 -0

@@ -314,7 +314,7 @@ struct kvm_regs {

4.12 KVM_SET_REGS

Capability: basic

Documentation/virtual/kvm/api.txt +1 -1

-Architectures: all
+Architectures: all except ARM

Type: vcpu ioctl
Parameters: struct kvm_regs (in)
Returns: 0 on success, -1 on error

Documentation/virtual/kvm/api.txt +0 -0

@@ -600,7 +600,7 @@ struct kvm_fpu {

Quoted 1 line

4.24 KVM_CREATE_IRQCHIP

Why KVM_GET_REGS/KVM_SET_REGS are not usable for arm?

Quoted 5 lines

Quoted 3 lines

We use the ONE_REG API instead and we don't want to support two separate APIs to user space.

I suppose fetching all registers is not anywhere on a fast path in userspace :)

If it's ever going to be in a fast path, we will add MULTI_REG which will feature an array of ONE_REG structs to fetch multiple registers at once.

Quoted 39 lines · Alexander Graf

Quoted 37 lines · Gleb Natapov

Quoted 31 lines · Christoffer Dall

Quoted 20 lines · Gleb Natapov

A couple of general question about ABI. If they were already answered just refer me to the previous discussion.

Quoted 16 lines · Christoffer Dall

Documentation/virtual/kvm/api.txt +0 -0

index a4df553..4237c27 100644
@@ -293,7 +293,7 @@ kvm_run' (see below).

4.11 KVM_GET_REGS

Capability: basic

Documentation/virtual/kvm/api.txt +1 -1

-Architectures: all
+Architectures: all except ARM

Type: vcpu ioctl
Parameters: struct kvm_regs (out)
Returns: 0 on success, -1 on error

Documentation/virtual/kvm/api.txt +0 -0

@@ -314,7 +314,7 @@ struct kvm_regs {

4.12 KVM_SET_REGS

Quoted 10 lines

Quoted 8 lines

Capability: basic

Documentation/virtual/kvm/api.txt +1 -1

-Architectures: all
+Architectures: all except ARM

Type: vcpu ioctl
Parameters: struct kvm_regs (in)
Returns: 0 on success, -1 on error

Documentation/virtual/kvm/api.txt +0 -0

@@ -600,7 +600,7 @@ struct kvm_fpu {

4.24 KVM_CREATE_IRQCHIP

Why KVM_GET_REGS/KVM_SET_REGS are not usable for arm?

Quoted 3 lines

We use the ONE_REG API instead and we don't want to support two separate APIs to user space.

I suppose fetching all registers is not anywhere on a fast path in userspace :)

Quoted 2 lines

If it's ever going to be in a fast path, we will add MULTI_REG which will feature an array of ONE_REG structs to fetch multiple registers at once.

And I hope it will not be. On x86 only the broken vmware PV interface requires reading registers for emulation.

This reminds me the question I wanted to ask you about ONE_REG interface. Why architecture is encoded in register name? Is architecture implied by HW the code is running on anyway?

Sets up KVM code to handle all exceptions taken to Hyp mode.

When the kernel is booted in Hyp mode, calling an hvc instruction with r0 pointing to the new vectors, the HVBAR is changed to the the vector pointers. This allows subsystems (like KVM here) to execute code in Hyp-mode with the MMU disabled.

We initialize other Hyp-mode registers and enables the MMU for Hyp-mode from the id-mapped hyp initialization code. Afterwards, the HVBAR is changed to point to KVM Hyp vectors used to catch guest faults and to switch to Hyp mode to perform a world-switch into a KVM guest.

Also provides memory mapping code to map required code pages, data structures, and I/O regions accessed in Hyp mode at the same virtual address as the host kernel virtual addresses, but which conforms to the architectural requirements for translations in Hyp mode. This interface is added in arch/arm/kvm/arm_mmu.c and comprises:
- create_hyp_mappings(from, to);
- create_hyp_io_mappings(from, to, phys_addr);
- free_hyp_pmds();

arch/arm/kvm/arm.c +32 -0

index 82cb338..2dddc58 100644
@@ -34,11 +34,21 @@
 #include <asm/ptrace.h>
 #include <asm/mman.h>
 #include <asm/cputype.h>
+#include <asm/tlbflush.h>
+#include <asm/virt.h>
+#include <asm/kvm_arm.h>
+#include <asm/kvm_asm.h>
+#include <asm/kvm_mmu.h>
 
 #ifdef REQUIRES_VIRT
 __asm__(".arch_extension       virt");
 #endif
 
+static DEFINE_PER_CPU(unsigned long, kvm_arm_hyp_stack_page);
+static struct vfp_hard_struct __percpu *kvm_host_vfp_state;
+static unsigned long hyp_default_vectors;
+
+
 int kvm_arch_hardware_enable(void *garbage)
 {
        return 0;

@@ -336,9 +346,176 @@ long kvm_arch_vm_ioctl(struct file *filp,
        return -EINVAL;
 }
 
+static void cpu_init_hyp_mode(void *vector)
+{
+       unsigned long long pgd_ptr;
+       unsigned long hyp_stack_ptr;
+       unsigned long stack_page;
+       unsigned long vector_ptr;
+
+       /* Switch from the HYP stub to our own HYP init vector */
+       __hyp_set_vectors((unsigned long)vector);
+
+       pgd_ptr = (unsigned long long)kvm_mmu_get_httbr();
+       stack_page = __get_cpu_var(kvm_arm_hyp_stack_page);
+       hyp_stack_ptr = stack_page + PAGE_SIZE;
+       vector_ptr = (unsigned long)__kvm_hyp_vector;
+
+       /*
+        * Call initialization code, and switch to the full blown
+        * HYP code. The init code corrupts r12, so set the clobber
+        * list accordingly.
+        */
+       asm volatile (
+               "mov    r0, %[pgd_ptr_low]\n\t"

Quoted 20 lines · Christoffer Dall

Sets up KVM code to handle all exceptions taken to Hyp mode.

When the kernel is booted in Hyp mode, calling an hvc instruction with r0 pointing to the new vectors, the HVBAR is changed to the the vector pointers. This allows subsystems (like KVM here) to execute code in Hyp-mode with the MMU disabled.

We initialize other Hyp-mode registers and enables the MMU for Hyp-mode from the id-mapped hyp initialization code. Afterwards, the HVBAR is changed to point to KVM Hyp vectors used to catch guest faults and to switch to Hyp mode to perform a world-switch into a KVM guest.

Also provides memory mapping code to map required code pages, data structures, and I/O regions accessed in Hyp mode at the same virtual address as the host kernel virtual addresses, but which conforms to the architectural requirements for translations in Hyp mode. This interface is added in arch/arm/kvm/arm_mmu.c and comprises:
- create_hyp_mappings(from, to);
- create_hyp_io_mappings(from, to, phys_addr);
- free_hyp_pmds();

[...]

Quoted 56 lines

arch/arm/kvm/arm.c +36 -0

index 82cb338..2dddc58 100644
@@ -34,11 +34,21 @@
 #include <asm/ptrace.h>
 #include <asm/mman.h>
 #include <asm/cputype.h>
+#include <asm/tlbflush.h>
+#include <asm/virt.h>
+#include <asm/kvm_arm.h>
+#include <asm/kvm_asm.h>
+#include <asm/kvm_mmu.h>
 
 #ifdef REQUIRES_VIRT
 __asm__(".arch_extension       virt");
 #endif
 
+static DEFINE_PER_CPU(unsigned long, kvm_arm_hyp_stack_page);
+static struct vfp_hard_struct __percpu *kvm_host_vfp_state;
+static unsigned long hyp_default_vectors;
+
+
 int kvm_arch_hardware_enable(void *garbage)
 {
        return 0;

@@ -336,9 +346,176 @@ long kvm_arch_vm_ioctl(struct file *filp,
        return -EINVAL;
 }
 
+static void cpu_init_hyp_mode(void *vector)
+{
+       unsigned long long pgd_ptr;
+       unsigned long hyp_stack_ptr;
+       unsigned long stack_page;
+       unsigned long vector_ptr;
+
+       /* Switch from the HYP stub to our own HYP init vector */
+       __hyp_set_vectors((unsigned long)vector);
+
+       pgd_ptr = (unsigned long long)kvm_mmu_get_httbr();
+       stack_page = __get_cpu_var(kvm_arm_hyp_stack_page);
+       hyp_stack_ptr = stack_page + PAGE_SIZE;
+       vector_ptr = (unsigned long)__kvm_hyp_vector;
+
+       /*
+        * Call initialization code, and switch to the full blown
+        * HYP code. The init code corrupts r12, so set the clobber
+        * list accordingly.
+        */
+       asm volatile (
+               "mov    r0, %[pgd_ptr_low]\n\t"
+               "mov    r1, %[pgd_ptr_high]\n\t"
+               "mov    r2, %[hyp_stack_ptr]\n\t"
+               "mov    r3, %[vector_ptr]\n\t"
+               "hvc    #0\n\t" : :

arch/arm/kvm/arm.c long kvm_arch_vm_ioctl(struct file *filp, · line 380

Quoted 6 lines

arch/arm/kvm/arm.c +6 -0

+               [pgd_ptr_low] "r" ((unsigned long)(pgd_ptr & 0xffffffff)),
+               [pgd_ptr_high] "r" ((unsigned long)(pgd_ptr >> 32ULL)),
+               [hyp_stack_ptr] "r" (hyp_stack_ptr),
+               [vector_ptr] "r" (vector_ptr) :
+               "r0", "r1", "r2", "r3", "r12");
+}

Use kvm_call_hyp here instead.

From: Christoffer Dall <[email protected]>

All interrupt injection is now based on the VM ioctl KVM_IRQ_LINE. This works semantically well for the GIC as we in fact raise/lower a line on a machine component (the gic). The IOCTL uses the follwing struct.

struct kvm_irq_level {
	union {
		__u32 irq;     /* GSI */
		__s32 status;  /* not used for KVM_IRQ_LEVEL */
	};
	__u32 level;           /* 0 or 1 */
};

ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip

(GIC), and for in-kernel irqchip can tell the GIC to use PPIs designated for specific cpus. The irq field is interpreted like this:

 ?bits:  | 31 ... 24 | 23  ... 16 | 15    ...    0 |
  field: | irq_type  | vcpu_index |   irq_number   |

The irq_type field has the following values:
- irq_type[0]: out-of-kernel GIC: irq_number 0 is IRQ, irq_number 1 is FIQ
- irq_type[1]: in-kernel GIC: SPI, irq_number between 32 and 1019 (incl.) (the vcpu_index field is ignored)
- irq_type[2]: in-kernel GIC: PPI, irq_number between 16 and 31 (incl.)

The irq_number thus corresponds to the irq ID in as in the GICv2 specs.

This is documented in Documentation/kvm/api.txt.

Reviewed-by Marcelo Tosatti <[email protected]>

Signed-off-by Christoffer Dall <[email protected]>

---
 Documentation/virtual/kvm/api.txt |   25 ++++++++++++--
 arch/arm/include/asm/kvm_arm.h    |    1 +
 arch/arm/include/uapi/asm/kvm.h   |   21 ++++++++++++
 arch/arm/kvm/arm.c                |   65 +++++++++++++++++++++++++++++++++++++
 arch/arm/kvm/trace.h              |   25 ++++++++++++++
 include/uapi/linux/kvm.h          |    1 +
 6 files changed, 134 insertions(+), 4 deletions(-)

Documentation/virtual/kvm/api.txt +21 -4

index 4237c27..5050492 100644
@@ -615,15 +615,32 @@ created.
 4.25 KVM_IRQ_LINE
 
 Capability: KVM_CAP_IRQCHIP
-Architectures: x86, ia64
+Architectures: x86, ia64, arm
 Type: vm ioctl
 Parameters: struct kvm_irq_level
 Returns: 0 on success, -1 on error
 
 Sets the level of a GSI input to the interrupt controller model in the kernel.
-Requires that an interrupt controller model has been previously created with
-KVM_CREATE_IRQCHIP.  Note that edge-triggered interrupts require the level
-to be set to 1 and then back to 0.
+On some architectures it is required that an interrupt controller model has
+been previously created with KVM_CREATE_IRQCHIP.  Note that edge-triggered
+interrupts require the level to be set to 1 and then back to 0.
+
+ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip
+(GIC), and for in-kernel irqchip can tell the GIC to use PPIs designated for
+specific cpus.  The irq field is interpreted like this:
+
+ ?bits:  | 31 ... 24 | 23  ... 16 | 15    ...    0 |
+  field: | irq_type  | vcpu_index |     irq_id     |
+
+The irq_type field has the following values:
+- irq_type[0]: out-of-kernel GIC: irq_id 0 is IRQ, irq_id 1 is FIQ
+- irq_type[1]: in-kernel GIC: SPI, irq_id between 32 and 1019 (incl.)
+               (the vcpu_index field is ignored)
+- irq_type[2]: in-kernel GIC: PPI, irq_id between 16 and 31 (incl.)
+
+(The irq_id field thus corresponds nicely to the IRQ ID in the ARM GIC specs)
+
+In both cases, level is used to raise/lower the line.
 
 struct kvm_irq_level {
 	union {

arch/arm/include/asm/kvm_arm.h +1 -0

index 613afe2..fb22ee8 100644
@@ -68,6 +68,7 @@
 #define HCR_GUEST_MASK (HCR_TSC | HCR_TSW | HCR_TWI | HCR_VM | HCR_BSU_IS | \
 			HCR_FB | HCR_TAC | HCR_AMO | HCR_IMO | HCR_FMO | \
 			HCR_SWIO | HCR_TIDCP)
+#define HCR_VIRT_EXCP_MASK (HCR_VA | HCR_VI | HCR_VF)
 
 /* Hyp System Control Register (HSCTLR) bits */
 #define HSCTLR_TE	(1 << 30)

arch/arm/include/uapi/asm/kvm.h +21 -0

index c6298b1..4cf6d8f 100644
@@ -23,6 +23,7 @@
 #include <asm/ptrace.h>
 
 #define __KVM_HAVE_GUEST_DEBUG
+#define __KVM_HAVE_IRQ_LINE
 
 #define KVM_REG_SIZE(id)						\
 	(1U << (((id) & KVM_REG_SIZE_MASK) >> KVM_REG_SIZE_SHIFT))

@@ -103,4 +104,24 @@ struct kvm_arch_memory_slot {
 #define KVM_REG_ARM_CORE		(0x0010 << KVM_REG_ARM_COPROC_SHIFT)
 #define KVM_REG_ARM_CORE_REG(name)	(offsetof(struct kvm_regs, name) / 4)
 
+/* KVM_IRQ_LINE irq field index values */
+#define KVM_ARM_IRQ_TYPE_SHIFT		24
+#define KVM_ARM_IRQ_TYPE_MASK		0xff
+#define KVM_ARM_IRQ_VCPU_SHIFT		16
+#define KVM_ARM_IRQ_VCPU_MASK		0xff
+#define KVM_ARM_IRQ_NUM_SHIFT		0
+#define KVM_ARM_IRQ_NUM_MASK		0xffff
+
+/* irq_type field */
+#define KVM_ARM_IRQ_TYPE_CPU		0
+#define KVM_ARM_IRQ_TYPE_SPI		1
+#define KVM_ARM_IRQ_TYPE_PPI		2
+
+/* out-of-kernel GIC cpu interrupt injection irq_number field */
+#define KVM_ARM_IRQ_CPU_IRQ		0
+#define KVM_ARM_IRQ_CPU_FIQ		1
+
+/* Highest supported SPI, from VGIC_NR_IRQS */
+#define KVM_ARM_IRQ_GIC_MAX		127
+
 #endif /* __ARM_KVM_H__ */

arch/arm/kvm/arm.c +65 -0

index ab82039..9b4566e 100644
@@ -24,6 +24,7 @@
 #include <linux/fs.h>
 #include <linux/mman.h>
 #include <linux/sched.h>
+#include <linux/kvm.h>
 #include <trace/events/kvm.h>
 
 #define CREATE_TRACE_POINTS

@@ -284,6 +285,7 @@ void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu)
 
 void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
 {
+	vcpu->cpu = cpu;
 }
 
 void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)

@@ -324,6 +326,69 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
 	return -EINVAL;
 }
 
+static int vcpu_interrupt_line(struct kvm_vcpu *vcpu, int number, bool level)
+{
+	int bit_index;
+	bool set;
+	unsigned long *ptr;
+
+	if (number == KVM_ARM_IRQ_CPU_IRQ)
+		bit_index = __ffs(HCR_VI);
+	else /* KVM_ARM_IRQ_CPU_FIQ */
+		bit_index = __ffs(HCR_VF);
+
+	ptr = (unsigned long *)&vcpu->arch.irq_lines;
+	if (level)
+		set = test_and_set_bit(bit_index, ptr);
+	else
+		set = test_and_clear_bit(bit_index, ptr);
+
+	/*
+	 * If we didn't change anything, no need to wake up or kick other CPUs
+	 */
+	if (set == level)
+		return 0;
+
+	/*
+	 * The vcpu irq_lines field was updated, wake up sleeping VCPUs and
+	 * trigger a world-switch round on the running physical CPU to set the
+	 * virtual IRQ/FIQ fields in the HCR appropriately.
+	 */
+	kvm_vcpu_kick(vcpu);
+
+	return 0;
+}
+
+int kvm_vm_ioctl_irq_line(struct kvm *kvm, struct kvm_irq_level *irq_level)
+{
+	u32 irq = irq_level->irq;
+	unsigned int irq_type, vcpu_idx, irq_num;
+	int nrcpus = atomic_read(&kvm->online_vcpus);
+	struct kvm_vcpu *vcpu = NULL;
+	bool level = irq_level->level;
+
+	irq_type = (irq >> KVM_ARM_IRQ_TYPE_SHIFT) & KVM_ARM_IRQ_TYPE_MASK;
+	vcpu_idx = (irq >> KVM_ARM_IRQ_VCPU_SHIFT) & KVM_ARM_IRQ_VCPU_MASK;
+	irq_num = (irq >> KVM_ARM_IRQ_NUM_SHIFT) & KVM_ARM_IRQ_NUM_MASK;
+
+	trace_kvm_irq_line(irq_type, vcpu_idx, irq_num, irq_level->level);
+
+	if (irq_type != KVM_ARM_IRQ_TYPE_CPU)
+		return -EINVAL;
+
+	if (vcpu_idx >= nrcpus)
+		return -EINVAL;
+
+	vcpu = kvm_get_vcpu(kvm, vcpu_idx);
+	if (!vcpu)
+		return -EINVAL;
+
+	if (irq_num > KVM_ARM_IRQ_CPU_FIQ)
+		return -EINVAL;
+
+	return vcpu_interrupt_line(vcpu, irq_num, level);
+}
+
 long kvm_arch_vcpu_ioctl(struct file *filp,
 			 unsigned int ioctl, unsigned long arg)
 {

arch/arm/kvm/trace.h +25 -0

index 862b2cc..105d1f7 100644
@@ -39,6 +39,31 @@ TRACE_EVENT(kvm_exit,
 	TP_printk("PC: 0x%08lx", __entry->vcpu_pc)
 );
 
+TRACE_EVENT(kvm_irq_line,
+	TP_PROTO(unsigned int type, int vcpu_idx, int irq_num, int level),
+	TP_ARGS(type, vcpu_idx, irq_num, level),
+
+	TP_STRUCT__entry(
+		__field(	unsigned int,	type		)
+		__field(	int,		vcpu_idx	)
+		__field(	int,		irq_num		)
+		__field(	int,		level		)
+	),
+
+	TP_fast_assign(
+		__entry->type		= type;
+		__entry->vcpu_idx	= vcpu_idx;
+		__entry->irq_num	= irq_num;
+		__entry->level		= level;
+	),
+
+	TP_printk("Inject %s interrupt (%d), vcpu->idx: %d, num: %d, level: %d",
+		  (__entry->type == KVM_ARM_IRQ_TYPE_CPU) ? "CPU" :
+		  (__entry->type == KVM_ARM_IRQ_TYPE_PPI) ? "VGIC PPI" :
+		  (__entry->type == KVM_ARM_IRQ_TYPE_SPI) ? "VGIC SPI" : "UNKNOWN",
+		  __entry->type, __entry->vcpu_idx, __entry->irq_num, __entry->level)
+);
+
 TRACE_EVENT(kvm_unmap_hva,
 	TP_PROTO(unsigned long hva),
 	TP_ARGS(hva),

include/uapi/linux/kvm.h +1 -1

index 24978d5..dc63665 100644
@@ -115,6 +115,7 @@ struct kvm_irq_level {
 	 * ACPI gsi notion of irq.
 	 * For IA-64 (APIC model) IOAPIC0: irq 0-23; IOAPIC1: irq 24-47..
 	 * For X86 (standard AT mode) PIC0/1: irq 0-15. IOAPIC0: 0-23..
+	 * For ARM: See Documentation/virtual/kvm/api.txt
 	 */
 	union {
 		__u32 irq;
 
--

To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 14 lines · Christoffer Dall

From: Christoffer Dall <[email protected]>

All interrupt injection is now based on the VM ioctl KVM_IRQ_LINE. This works semantically well for the GIC as we in fact raise/lower a line on a machine component (the gic). The IOCTL uses the follwing struct.

struct kvm_irq_level {
      union {
              __u32 irq;     /* GSI */
              __s32 status;  /* not used for KVM_IRQ_LEVEL */
      };
      __u32 level;           /* 0 or 1 */
};

Quoted 1 line

ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip

CPU level interrupt should use KVM_INTERRUPT instead.

Quoted 3 lines

(GIC), and for in-kernel irqchip can tell the GIC to use PPIs designated for specific cpus. The irq field is interpreted like this:

Haven't read about GIC yet. Is PPI an interrupt that device can send directly to a specific CPU? Can we model that with irq routing like we do for MSI?

Quoted 15 lines · Gleb Natapov

Quoted 14 lines · Christoffer Dall

From: Christoffer Dall <[email protected]>

All interrupt injection is now based on the VM ioctl KVM_IRQ_LINE. This works semantically well for the GIC as we in fact raise/lower a line on a machine component (the gic). The IOCTL uses the follwing struct.

struct kvm_irq_level {
      union {
              __u32 irq;     /* GSI */
              __s32 status;  /* not used for KVM_IRQ_LEVEL */
      };
      __u32 level;           /* 0 or 1 */
};

Quoted 2 lines

Quoted 1 line

ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip

CPU level interrupt should use KVM_INTERRUPT instead.

No, that would be wrong. KVM_INTERRUPT is for interrupts which must be delivered synchronously to the CPU. KVM_IRQ_LINE is for interrupts which can be fed to the kernel asynchronously. It happens that on x86 "must be delivered synchronously" and "not going to in kernel irqchip" are the same, but this isn't true for other archs. For ARM all our interrupts can be fed to the kernel
asynchronously, and so we use KVM_IRQ_LINE in all cases.

There was a big discussion thread about this on kvm and qemu-devel last July (and we cleaned up some of the QEMU code to not smoosh together all these different concepts under "do I have an irqchip or not?").

Quoted 7 lines

Quoted 4 lines

(GIC), and for in-kernel irqchip can tell the GIC to use PPIs designated for specific cpus. The irq field is interpreted like this:

Haven't read about GIC yet. Is PPI an interrupt that device can send directly to a specific CPU? Can we model that with irq routing like we do for MSI?

There is no routing involved -- you are raising a specific signal line (which happens to result in prodding a particular CPU), that's all.

Quoted 11 lines · Peter Maydell

Quoted 2 lines · Gleb Natapov

Quoted 1 line

ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip

CPU level interrupt should use KVM_INTERRUPT instead.

No, that would be wrong. KVM_INTERRUPT is for interrupts which must be delivered synchronously to the CPU. KVM_IRQ_LINE is for interrupts which can be fed to the kernel asynchronously. It happens that on x86 "must be delivered synchronously" and "not going to in kernel irqchip" are the same, but this isn't true for other archs. For ARM all our interrupts can be fed to the kernel asynchronously, and so we use KVM_IRQ_LINE in all cases.

I do no quite understand what you mean by synchronously and asynchronously.

The difference between KVM_INTERRUPT and KVM_IRQ_LINE line is that former is used when destination cpu is known to userspace later is used when kernel code is involved in figuring out the destination.

The
injections themselves are currently synchronous for both of them on x86 and ARM. i.e vcpu is kicked out from guest mode when interrupt need to be injected into a guest and vcpu state is changed to inject interrupt during next guest entry. In the near feature x86 will be able to inject interrupt without kicking vcpu out from the guest mode does ARM plan to do the same? For GIC interrupts or for IRQ/FIQ or for both?

Quoted 3 lines

There was a big discussion thread about this on kvm and qemu-devel last July (and we cleaned up some of the QEMU code to not smoosh together all these different concepts under "do I have an irqchip or not?").

Do you have a pointer?

Quoted 13 lines · Gleb Natapov

Quoted 11 lines · Peter Maydell

Quoted 2 lines · Gleb Natapov

Quoted 1 line

ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip

CPU level interrupt should use KVM_INTERRUPT instead.

No, that would be wrong. KVM_INTERRUPT is for interrupts which must be delivered synchronously to the CPU. KVM_IRQ_LINE is for interrupts which can be fed to the kernel asynchronously. It happens that on x86 "must be delivered synchronously" and "not going to in kernel irqchip" are the same, but this isn't true for other archs. For ARM all our interrupts can be fed to the kernel asynchronously, and so we use KVM_IRQ_LINE in all cases.

Quoted 2 lines

I do no quite understand what you mean by synchronously and asynchronously.

Synchronously: the vcpu has to be stopped and userspace then feeds in the interrupt to be taken when the guest is resumed.
Asynchronously: any old thread can tell the kernel there's an interrupt, and the guest vcpu then deals with it when needed (the vcpu thread may leave the guest but doesn't come out of the host kernel to qemu).

Quoted 3 lines

The difference between KVM_INTERRUPT and KVM_IRQ_LINE line is that former is used when destination cpu is known to userspace later is used when kernel code is involved in figuring out the destination.

This doesn't match up with Avi's explanation at all.

Quoted 8 lines

The
injections themselves are currently synchronous for both of them on x86 and ARM. i.e vcpu is kicked out from guest mode when interrupt need to be injected into a guest and vcpu state is changed to inject interrupt during next guest entry. In the near feature x86 will be able to inject interrupt without kicking vcpu out from the guest mode does ARM plan to do the same? For GIC interrupts or for IRQ/FIQ or for both?

Quoted 4 lines

Quoted 3 lines

There was a big discussion thread about this on kvm and qemu-devel last July (and we cleaned up some of the QEMU code to not smoosh together all these different concepts under "do I have an irqchip or not?").

Do you have a pointer?

http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02460.html
and there was a later longer (but less clear) thread which included this mail from Avi:
http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02872.html
basically explaining that the reason for the weird synchronous KVM_INTERRUPT API is that it's emulating a weird synchronous hardware interface which is specific to x86. ARM doesn't have a synchronous interface in the same way, so it's much more straightforward to use KVM_IRQ_LINE.

Quoted 13 lines · Gleb Natapov

Quoted 11 lines · Peter Maydell

Quoted 2 lines · Gleb Natapov

Quoted 1 line

ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip

CPU level interrupt should use KVM_INTERRUPT instead.

No, that would be wrong. KVM_INTERRUPT is for interrupts which must be delivered synchronously to the CPU. KVM_IRQ_LINE is for interrupts which can be fed to the kernel asynchronously. It happens that on x86 "must be delivered synchronously" and "not going to in kernel irqchip" are the same, but this isn't true for other archs. For ARM all our interrupts can be fed to the kernel asynchronously, and so we use KVM_IRQ_LINE in all cases.

Quoted 2 lines

I do no quite understand what you mean by synchronously and asynchronously.

Synchronously: the vcpu has to be stopped and userspace then feeds in the interrupt to be taken when the guest is resumed.
Asynchronously: any old thread can tell the kernel there's an interrupt, and the guest vcpu then deals with it when needed (the vcpu thread may leave the guest but doesn't come out of the host kernel to qemu).

Quoted 3 lines

The difference between KVM_INTERRUPT and KVM_IRQ_LINE line is that former is used when destination cpu is known to userspace later is used when kernel code is involved in figuring out the destination.

This doesn't match up with Avi's explanation at all.

Quoted 8 lines

The
injections themselves are currently synchronous for both of them on x86 and ARM. i.e vcpu is kicked out from guest mode when interrupt need to be injected into a guest and vcpu state is changed to inject interrupt during next guest entry. In the near feature x86 will be able to inject interrupt without kicking vcpu out from the guest mode does ARM plan to do the same? For GIC interrupts or for IRQ/FIQ or for both?

Quoted 4 lines

Quoted 3 lines

There was a big discussion thread about this on kvm and qemu-devel last July (and we cleaned up some of the QEMU code to not smoosh together all these different concepts under "do I have an irqchip or not?").

Do you have a pointer?

http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02460.html
and there was a later longer (but less clear) thread which included this mail from Avi:
http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02872.html
basically explaining that the reason for the weird synchronous KVM_INTERRUPT API is that it's emulating a weird synchronous hardware interface which is specific to x86. ARM doesn't have a synchronous interface in the same way, so it's much more straightforward to use KVM_IRQ_LINE.

Quoted 41 lines · Peter Maydell

Quoted 11 lines · Gleb Natapov

Quoted 10 lines · Peter Maydell

Quoted 2 lines · Gleb Natapov

Quoted 1 line

ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip

CPU level interrupt should use KVM_INTERRUPT instead.

No, that would be wrong. KVM_INTERRUPT is for interrupts which must be delivered synchronously to the CPU. KVM_IRQ_LINE is for interrupts which can be fed to the kernel asynchronously. It happens that on x86 "must be delivered synchronously" and "not going to in kernel irqchip" are the same, but this isn't true for other archs. For ARM all our interrupts can be fed to the kernel asynchronously, and so we use KVM_IRQ_LINE in all cases.

Quoted 2 lines

I do no quite understand what you mean by synchronously and asynchronously.

Synchronously: the vcpu has to be stopped and userspace then feeds in the interrupt to be taken when the guest is resumed.
Asynchronously: any old thread can tell the kernel there's an interrupt, and the guest vcpu then deals with it when needed (the vcpu thread may leave the guest but doesn't come out of the host kernel to qemu).

Quoted 3 lines

The difference between KVM_INTERRUPT and KVM_IRQ_LINE line is that former is used when destination cpu is known to userspace later is used when kernel code is involved in figuring out the destination.

This doesn't match up with Avi's explanation at all.

Quoted 8 lines

The
injections themselves are currently synchronous for both of them on x86 and ARM. i.e vcpu is kicked out from guest mode when interrupt need to be injected into a guest and vcpu state is changed to inject interrupt during next guest entry. In the near feature x86 will be able to inject interrupt without kicking vcpu out from the guest mode does ARM plan to do the same? For GIC interrupts or for IRQ/FIQ or for both?

Quoted 4 lines

Quoted 3 lines

There was a big discussion thread about this on kvm and qemu-devel last July (and we cleaned up some of the QEMU code to not smoosh together all these different concepts under "do I have an irqchip or not?").

Do you have a pointer?

http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02460.html
and there was a later longer (but less clear) thread which included this mail from Avi:

Quoted 7 lines

   http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02872.html

basically explaining that the reason for the weird synchronous KVM_INTERRUPT API is that it's emulating a weird synchronous hardware interface which is specific to x86. ARM doesn't have a synchronous interface in the same way, so it's much more straightforward to use KVM_IRQ_LINE.

OK. I see. So basically Avi saw KVM_INTERRUPT as an oddball interface required only for APIC emulation in userspace. It is used for PIC also, where this is not strictly needed, but this is for historical reasons (KVM_IRQ_LINE was introduces late and it is GSI centric on x86).

Thank you for the pointer.

Quoted 54 lines · Gleb Natapov

Quoted 38 lines · Peter Maydell

Quoted 11 lines · Gleb Natapov

Quoted 10 lines · Peter Maydell

Quoted 2 lines · Gleb Natapov

Quoted 1 line

ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip

CPU level interrupt should use KVM_INTERRUPT instead.

No, that would be wrong. KVM_INTERRUPT is for interrupts which must be delivered synchronously to the CPU. KVM_IRQ_LINE is for interrupts which can be fed to the kernel asynchronously. It happens that on x86 "must be delivered synchronously" and "not going to in kernel irqchip" are the same, but this isn't true for other archs. For ARM all our interrupts can be fed to the kernel asynchronously, and so we use KVM_IRQ_LINE in all cases.

Quoted 2 lines

I do no quite understand what you mean by synchronously and asynchronously.

Synchronously: the vcpu has to be stopped and userspace then feeds in the interrupt to be taken when the guest is resumed.
Asynchronously: any old thread can tell the kernel there's an interrupt, and the guest vcpu then deals with it when needed (the vcpu thread may leave the guest but doesn't come out of the host kernel to qemu).

Quoted 3 lines

The difference between KVM_INTERRUPT and KVM_IRQ_LINE line is that former is used when destination cpu is known to userspace later is used when kernel code is involved in figuring out the destination.

This doesn't match up with Avi's explanation at all.

Quoted 8 lines

The
injections themselves are currently synchronous for both of them on x86 and ARM. i.e vcpu is kicked out from guest mode when interrupt need to be injected into a guest and vcpu state is changed to inject interrupt during next guest entry. In the near feature x86 will be able to inject interrupt without kicking vcpu out from the guest mode does ARM plan to do the same? For GIC interrupts or for IRQ/FIQ or for both?

Quoted 4 lines

Quoted 3 lines

There was a big discussion thread about this on kvm and qemu-devel last July (and we cleaned up some of the QEMU code to not smoosh together all these different concepts under "do I have an irqchip or not?").

Do you have a pointer?

Quoted 10 lines

http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02460.html
and there was a later longer (but less clear) thread which included this mail from Avi:
http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02872.html
basically explaining that the reason for the weird synchronous KVM_INTERRUPT API is that it's emulating a weird synchronous hardware interface which is specific to x86. ARM doesn't have a synchronous interface in the same way, so it's much more straightforward to use KVM_IRQ_LINE.

OK. I see. So basically Avi saw KVM_INTERRUPT as an oddball interface required only for APIC emulation in userspace. It is used for PIC also, where this is not strictly needed, but this is for historical reasons (KVM_IRQ_LINE was introduces late and it is GSI centric on x86).

Quoted 1 line

Thank you for the pointer.

Yeah, please keep in mind that KVM_INTERRUPT is not a unified interface either. In fact, it is asynchronous on PPC :). And it's called KVM_S390_INTERRUPT on s390 and also asynchronous. X86 is the oddball here.

But I don't care whether we call the ioctl to steer CPU interrupt pins KVM_INTERRUPT, KVM_S390_INTERRUPT or KVM_IRQ_LINE, as long as the code makes it obvious what is happening.

Provides complete world-switch implementation to switch to other guests running in non-secure modes. Includes Hyp exception handlers that capture necessary exception information and stores the information on the VCPU and KVM structures.

The following Hyp-ABI is also documented in the code:

Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
Switching to Hyp mode is done through a simple HVC #0 instruction. The exception vector code will check that the HVC comes from VMID==0 and if so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- r0 contains a pointer to a HYP function
- r1, r2, and r3 contain arguments to the above function.
- The HYP function will be called with its arguments in r0, r1 and r2. On HYP function return, we return directly to SVC.

A call to a function executing in Hyp mode is performed like the following:

<svc code>
ldr r0, =BSYM(my_hyp_fn)
ldr r1, =my_param
hvc #0 ; Call my_hyp_fn(my_param) from HYP mode <svc code>

Otherwise, the world-switch is pretty straight-forward. All state that can be modified by the guest is first backed up on the Hyp stack and the VCPU values is loaded onto the hardware. State, which is not loaded, but theoretically modifiable by the guest is protected through the virtualiation features to generate a trap and cause software emulation. Upon guest returns, all state is restored from hardware onto the VCPU struct and the original state is restored from the Hyp-stack onto the hardware.

SMP support using the VMPIDR calculated on the basis of the host MPIDR and overriding the low bits with KVM vcpu_id contributed by Marc Zyngier.

Reuse of VMIDs has been implemented by Antonios Motakis and adapated from a separate patch into the appropriate patches introducing the functionality. Note that the VMIDs are stored per VM as required by the ARM architecture reference manual.

To support VFP/NEON we trap those instructions using the HPCTR. When we trap, we switch the FPU. After a guest exit, the VFP state is returned to the host. When disabling access to floating point instructions, we also mask FPEXC_EN in order to avoid the guest receiving Undefined instruction exceptions before we have a chance to switch back the floating point state. We are reusing vfp_hard_struct, so we depend on VFPv3 being enabled in the host kernel, if not, we still trap cp10 and cp11 in order to inject an undefined instruction exception whenever the guest tries to use VFP/NEON. VFP/NEON developed by Antionios Motakis and Rusty Russell.

Aborts that are permission faults, and not stage-1 page table walk, do not report the faulting address in the HPFAR. We have to resolve the IPA, and store it just like the HPFAR register on the VCPU struct. If the IPA cannot be resolved, it means another CPU is playing with the page tables, and we simply restart the guest. This quirk was fixed by Marc Zyngier.

Reviewed-by Marcelo Tosatti <[email protected]>

Signed-off-by Rusty Russell <[email protected]>

Signed-off-by Antonios Motakis <[email protected]>

Signed-off-by Marc Zyngier <[email protected]>

Signed-off-by Christoffer Dall <[email protected]>

---
 arch/arm/include/asm/kvm_arm.h  |   51 ++++
 arch/arm/include/asm/kvm_host.h |   10 +
 arch/arm/kernel/asm-offsets.c   |   25 ++
 arch/arm/kvm/arm.c              |  187 ++++++++++++++++
 arch/arm/kvm/interrupts.S       |  396 +++++++++++++++++++++++++++++++++++
 arch/arm/kvm/interrupts_head.S  |  443 +++++++++++++++++++++++++++++++++++++++
 6 files changed, 1108 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/kvm/interrupts_head.S

arch/arm/include/asm/kvm_arm.h +51 -0

index fb22ee8..a3262a2 100644
@@ -98,6 +98,18 @@
 #define TTBCR_T0SZ	3
 #define HTCR_MASK	(TTBCR_T0SZ | TTBCR_IRGN0 | TTBCR_ORGN0 | TTBCR_SH0)
 
+/* Hyp System Trap Register */
+#define HSTR_T(x)	(1 << x)
+#define HSTR_TTEE	(1 << 16)
+#define HSTR_TJDBX	(1 << 17)
+
+/* Hyp Coprocessor Trap Register */
+#define HCPTR_TCP(x)	(1 << x)
+#define HCPTR_TCP_MASK	(0x3fff)
+#define HCPTR_TASE	(1 << 15)
+#define HCPTR_TTA	(1 << 20)
+#define HCPTR_TCPAC	(1 << 31)
+
 /* Hyp Debug Configuration Register bits */
 #define HDCR_TDRA	(1 << 11)
 #define HDCR_TDOSA	(1 << 10)

@@ -144,6 +156,45 @@
 #else
 #define VTTBR_X		(5 - KVM_T0SZ)
 #endif
+#define VTTBR_BADDR_SHIFT (VTTBR_X - 1)
+#define VTTBR_BADDR_MASK  (((1LLU << (40 - VTTBR_X)) - 1) << VTTBR_BADDR_SHIFT)
+#define VTTBR_VMID_SHIFT  (48LLU)
+#define VTTBR_VMID_MASK	  (0xffLLU << VTTBR_VMID_SHIFT)
+
+/* Hyp Syndrome Register (HSR) bits */
+#define HSR_EC_SHIFT	(26)
+#define HSR_EC		(0x3fU << HSR_EC_SHIFT)
+#define HSR_IL		(1U << 25)
+#define HSR_ISS		(HSR_IL - 1)
+#define HSR_ISV_SHIFT	(24)
+#define HSR_ISV		(1U << HSR_ISV_SHIFT)
+#define HSR_FSC		(0x3f)
+#define HSR_FSC_TYPE	(0x3c)
+#define HSR_WNR		(1 << 6)
+
+#define FSC_FAULT	(0x04)
+#define FSC_PERM	(0x0c)
+
+/* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
+#define HPFAR_MASK	(~0xf)
 
+#define HSR_EC_UNKNOWN	(0x00)
+#define HSR_EC_WFI	(0x01)
+#define HSR_EC_CP15_32	(0x03)
+#define HSR_EC_CP15_64	(0x04)
+#define HSR_EC_CP14_MR	(0x05)
+#define HSR_EC_CP14_LS	(0x06)
+#define HSR_EC_CP_0_13	(0x07)
+#define HSR_EC_CP10_ID	(0x08)
+#define HSR_EC_JAZELLE	(0x09)
+#define HSR_EC_BXJ	(0x0A)
+#define HSR_EC_CP14_64	(0x0C)
+#define HSR_EC_SVC_HYP	(0x11)
+#define HSR_EC_HVC	(0x12)
+#define HSR_EC_SMC	(0x13)
+#define HSR_EC_IABT	(0x20)
+#define HSR_EC_IABT_HYP	(0x21)
+#define HSR_EC_DABT	(0x24)
+#define HSR_EC_DABT_HYP	(0x25)
 
 #endif /* __ARM_KVM_ARM_H__ */

arch/arm/include/asm/kvm_host.h +10 -0

index 1de6f0d..ddb09da 100644
@@ -21,6 +21,7 @@
 
 #include <asm/kvm.h>
 #include <asm/kvm_asm.h>
+#include <asm/fpstate.h>
 
 #define KVM_MAX_VCPUS CONFIG_KVM_ARM_MAX_VCPUS
 #define KVM_USER_MEM_SLOTS 32

@@ -85,6 +86,14 @@ struct kvm_vcpu_arch {
 	u32 hxfar;		/* Hyp Data/Inst Fault Address Register */
 	u32 hpfar;		/* Hyp IPA Fault Address Register */
 
+	/* Floating point registers (VFP and Advanced SIMD/NEON) */
+	struct vfp_hard_struct vfp_guest;
+	struct vfp_hard_struct *vfp_host;
+
+	/*
+	 * Anything that is not used directly from assembly code goes
+	 * here.
+	 */
 	/* Interrupt related fields */
 	u32 irq_lines;		/* IRQ and FIQ levels */
 

@@ -112,6 +121,7 @@ struct kvm_one_reg;
 int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
 int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
 u64 kvm_call_hyp(void *hypfn, ...);
+void force_vm_exit(const cpumask_t *mask);
 
 #define KVM_ARCH_WANT_MMU_NOTIFIER
 struct kvm;

arch/arm/kernel/asm-offsets.c +25 -0

index c985b48..c8b3272 100644
@@ -13,6 +13,9 @@
 #include <linux/sched.h>
 #include <linux/mm.h>
 #include <linux/dma-mapping.h>
+#ifdef CONFIG_KVM_ARM_HOST
+#include <linux/kvm_host.h>
+#endif
 #include <asm/cacheflush.h>
 #include <asm/glue-df.h>
 #include <asm/glue-pf.h>

@@ -146,5 +149,27 @@ int main(void)
   DEFINE(DMA_BIDIRECTIONAL,	DMA_BIDIRECTIONAL);
   DEFINE(DMA_TO_DEVICE,		DMA_TO_DEVICE);
   DEFINE(DMA_FROM_DEVICE,	DMA_FROM_DEVICE);
+#ifdef CONFIG_KVM_ARM_HOST
+  DEFINE(VCPU_KVM,		offsetof(struct kvm_vcpu, kvm));
+  DEFINE(VCPU_MIDR,		offsetof(struct kvm_vcpu, arch.midr));
+  DEFINE(VCPU_CP15,		offsetof(struct kvm_vcpu, arch.cp15));
+  DEFINE(VCPU_VFP_GUEST,	offsetof(struct kvm_vcpu, arch.vfp_guest));
+  DEFINE(VCPU_VFP_HOST,		offsetof(struct kvm_vcpu, arch.vfp_host));
+  DEFINE(VCPU_REGS,		offsetof(struct kvm_vcpu, arch.regs));
+  DEFINE(VCPU_USR_REGS,		offsetof(struct kvm_vcpu, arch.regs.usr_regs));
+  DEFINE(VCPU_SVC_REGS,		offsetof(struct kvm_vcpu, arch.regs.svc_regs));
+  DEFINE(VCPU_ABT_REGS,		offsetof(struct kvm_vcpu, arch.regs.abt_regs));
+  DEFINE(VCPU_UND_REGS,		offsetof(struct kvm_vcpu, arch.regs.und_regs));
+  DEFINE(VCPU_IRQ_REGS,		offsetof(struct kvm_vcpu, arch.regs.irq_regs));
+  DEFINE(VCPU_FIQ_REGS,		offsetof(struct kvm_vcpu, arch.regs.fiq_regs));
+  DEFINE(VCPU_PC,		offsetof(struct kvm_vcpu, arch.regs.usr_regs.ARM_pc));
+  DEFINE(VCPU_CPSR,		offsetof(struct kvm_vcpu, arch.regs.usr_regs.ARM_cpsr));
+  DEFINE(VCPU_IRQ_LINES,	offsetof(struct kvm_vcpu, arch.irq_lines));
+  DEFINE(VCPU_HSR,		offsetof(struct kvm_vcpu, arch.hsr));
+  DEFINE(VCPU_HxFAR,		offsetof(struct kvm_vcpu, arch.hxfar));
+  DEFINE(VCPU_HPFAR,		offsetof(struct kvm_vcpu, arch.hpfar));
+  DEFINE(VCPU_HYP_PC,		offsetof(struct kvm_vcpu, arch.hyp_pc));
+  DEFINE(KVM_VTTBR,		offsetof(struct kvm, arch.vttbr));
+#endif
   return 0; 
 }

arch/arm/kvm/arm.c +8 -0

index 9b4566e..c94d278 100644
@@ -40,6 +40,7 @@
 #include <asm/kvm_arm.h>
 #include <asm/kvm_asm.h>
 #include <asm/kvm_mmu.h>
+#include <asm/kvm_emulate.h>
 
 #ifdef REQUIRES_VIRT
 __asm__(".arch_extension	virt");

@@ -49,6 +50,10 @@ static DEFINE_PER_CPU(unsigned long, kvm_arm_hyp_stack_page);
 static struct vfp_hard_struct __percpu *kvm_host_vfp_state;
 static unsigned long hyp_default_vectors;
 
+/* The VMID used in the VTTBR */
+static atomic64_t kvm_vmid_gen = ATOMIC64_INIT(1);
+static u8 kvm_next_vmid;
+static DEFINE_SPINLOCK(kvm_vmid_lock);
 
 int kvm_arch_hardware_enable(void *garbage)
 {

@@ -276,6 +281,8 @@ int __attribute_const__ kvm_target_cpu(void)
 
 int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
 {
+	/* Force users to call KVM_ARM_VCPU_INIT */
+	vcpu->arch.target = -1;
 	return 0;
 }
 

@@ -286,6 +293,7 @@ void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu)
 void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
 {
 	vcpu->cpu = cpu;
+	vcpu->arch.vfp_host = this_cpu_ptr(kvm_host_vfp_state);
 }
 
 void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)

arch/arm/kvm/arm.c +128 -1

+
+/**
+ * need_new_vmid_gen - check that the VMID is still valid
+ * @kvm: The VM's VMID to checkt
+ *
+ * return true if there is a new generation of VMIDs being used
+ *
+ * The hardware supports only 256 values with the value zero reserved for the
+ * host, so we check if an assigned value belongs to a previous generation,
+ * which which requires us to assign a new value. If we're the first to use a
+ * VMID for the new generation, we must flush necessary caches and TLBs on all
+ * CPUs.
+ */
+static bool need_new_vmid_gen(struct kvm *kvm)
+{
+	return unlikely(kvm->arch.vmid_gen != atomic64_read(&kvm_vmid_gen));
+}
+
+/**
+ * update_vttbr - Update the VTTBR with a valid VMID before the guest runs
+ * @kvm	The guest that we are about to run
+ *
+ * Called from kvm_arch_vcpu_ioctl_run before entering the guest to ensure the
+ * VM has a valid VMID, otherwise assigns a new one and flushes corresponding
+ * caches and TLBs.
+ */
+static void update_vttbr(struct kvm *kvm)
+{
+	phys_addr_t pgd_phys;
+	u64 vmid;
+
+	if (!need_new_vmid_gen(kvm))
+		return;
+
+	spin_lock(&kvm_vmid_lock);
+
+	/*
+	 * We need to re-check the vmid_gen here to ensure that if another vcpu
+	 * already allocated a valid vmid for this vm, then this vcpu should
+	 * use the same vmid.
+	 */
+	if (!need_new_vmid_gen(kvm)) {
+		spin_unlock(&kvm_vmid_lock);
+		return;
+	}
+
+	/* First user of a new VMID generation? */
+	if (unlikely(kvm_next_vmid == 0)) {
+		atomic64_inc(&kvm_vmid_gen);
+		kvm_next_vmid = 1;
+
+		/*
+		 * On SMP we know no other CPUs can use this CPU's or each
+		 * other's VMID after force_vm_exit returns since the
+		 * kvm_vmid_lock blocks them from reentry to the guest.
+		 */
+		force_vm_exit(cpu_all_mask);
+		/*
+		 * Now broadcast TLB + ICACHE invalidation over the inner
+		 * shareable domain to make sure all data structures are
+		 * clean.
+		 */
+		kvm_call_hyp(__kvm_flush_vm_context);
+	}
+
+	kvm->arch.vmid_gen = atomic64_read(&kvm_vmid_gen);
+	kvm->arch.vmid = kvm_next_vmid;
+	kvm_next_vmid++;
+
+	/* update vttbr to be used with the new vmid */
+	pgd_phys = virt_to_phys(kvm->arch.pgd);
+	vmid = ((u64)(kvm->arch.vmid) << VTTBR_VMID_SHIFT) & VTTBR_VMID_MASK;
+	kvm->arch.vttbr = pgd_phys & VTTBR_BADDR_MASK;
+	kvm->arch.vttbr |= vmid;
+
+	spin_unlock(&kvm_vmid_lock);
+}
+
+/*
+ * Return > 0 to return to guest, < 0 on error, 0 (and set exit_reason) on
+ * proper exit to QEMU.
+ */
+static int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
+		       int exception_index)
+{
+	run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
 	return 0;
 }
 
+/**
+ * kvm_arch_vcpu_ioctl_run - the main VCPU run function to execute guest code
+ * @vcpu:	The VCPU pointer
+ * @run:	The kvm_run structure pointer used for userspace state exchange
+ *
+ * This function is called through the VCPU_RUN ioctl called from user space. It
+ * will execute VM code in a loop until the time slice for the process is used
+ * or some emulation is needed from user space in which case the function will
+ * return with return value 0 and with the kvm_run structure filled in with the
+ * required data for the requested emulation.
+ */
 int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
 {
-	return -EINVAL;
+	int ret;
+	sigset_t sigsaved;
+
+	/* Make sure they initialize the vcpu with KVM_ARM_VCPU_INIT */
+	if (unlikely(vcpu->arch.target < 0))
+		return -ENOEXEC;
+
+	if (vcpu->sigset_active)
+		sigprocmask(SIG_SETMASK, &vcpu->sigset, &sigsaved);
+
+	ret = 1;
+	run->exit_reason = KVM_EXIT_UNKNOWN;
+	while (ret > 0) {
+		/*
+		 * Check conditions before entering the guest
+		 */
+		cond_resched();
+
+		update_vttbr(vcpu->kvm);
+
+		local_irq_disable();
+
+		/*
+		 * Re-check atomic conditions
+		 */
+		if (signal_pending(current)) {
+			ret = -EINTR;
+			run->exit_reason = KVM_EXIT_INTR;
+		}
+
+		if (ret <= 0 || need_new_vmid_gen(vcpu->kvm)) {