Add minimal support for Cortex A15 for ARM KVM

This patch adds minimal support for Cortex A15 to run under ARM KVM, which pavesthe way to ARM interrupt/time virtualization.

Patches are based on:
git://git.ncl.cs.columbia.edu/pub/git/qemu

For how to setup ARM KVM environment, please refer:
http://wiki.ncl.cs.columbia.edu/wiki/KVMARM:Guides:Development_Environment

 Makefile.target     |    2 +-
 hw/a15mpcore.c      |  146 ++++++++++++++++++++++++++++++++++++++
 hw/vexpress.c       |  192 +++++++++++++++++++++++++++++++++++++++++++++++++++
 target-arm/cpu.h    |    1 +
 target-arm/helper.c |   31 ++++++++
 5 files changed, 371 insertions(+), 1 deletions(-)
 create mode 100644 hw/a15mpcore.c

From: Bill Carson <[email protected]>

This patch add some A15 codes which enables ARM KVM could run Guest OS build with Versatile Express Cortex-A15x4 tile.

---
 Makefile.target     |    2 +-
 hw/a15mpcore.c      |  146 ++++++++++++++++++++++++++++++++++++++
 hw/vexpress.c       |  192 +++++++++++++++++++++++++++++++++++++++++++++++++++
 target-arm/cpu.h    |    1 +
 target-arm/helper.c |   31 ++++++++
 5 files changed, 371 insertions(+), 1 deletions(-)
 create mode 100644 hw/a15mpcore.c

index 2501c63..3899869 100644
@@ -331,7 +331,7 @@ endif
 obj-arm-y = integratorcp.o versatilepb.o arm_pic.o arm_timer.o
 obj-arm-y += arm_boot.o pl011.o pl031.o pl050.o pl080.o pl110.o pl181.o pl190.o
 obj-arm-y += versatile_pci.o
-obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o
+obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o a15mpcore.o
 obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o
 obj-arm-y += pl061.o
 obj-arm-y += arm-semi.o

index b8e7419..94b42ab 100644
@@ -419,6 +419,7 @@ void cpu_arm_set_cp_io(CPUARMState *env, int cpnum,
 #define ARM_CPUID_ARM11MPCORE 0x410fb022
 #define ARM_CPUID_CORTEXA8    0x410fc080
 #define ARM_CPUID_CORTEXA9    0x410fc090
+#define ARM_CPUID_CORTEXA15   0x410fc0f0
 #define ARM_CPUID_CORTEXM3    0x410fc231
 #define ARM_CPUID_ANY         0xffffffff
 

index b051b8c..c7a0ac9 100644
@@ -153,6 +153,36 @@ static void cpu_reset_model_id(CPUARMState *env, uint32_t id)
         env->cp15.c0_ccsid[1] = 0x200fe015; /* 16k L1 icache. */
         env->cp15.c1_sys = 0x00c50078;
         break;
+    case ARM_CPUID_CORTEXA15: /* most same as A9 */
+        set_feature(env, ARM_FEATURE_V4T);
+        set_feature(env, ARM_FEATURE_V5);
+        set_feature(env, ARM_FEATURE_V6);
+        set_feature(env, ARM_FEATURE_V6K);
+        set_feature(env, ARM_FEATURE_V7);
+        set_feature(env, ARM_FEATURE_AUXCR);
+        set_feature(env, ARM_FEATURE_THUMB2);
+        set_feature(env, ARM_FEATURE_VFP);
+        set_feature(env, ARM_FEATURE_VFP3);
+        set_feature(env, ARM_FEATURE_VFP_FP16);
+        set_feature(env, ARM_FEATURE_NEON);
+        set_feature(env, ARM_FEATURE_THUMB2EE);
+        /* Note that A9 supports the MP extensions even for
+         * A9UP and single-core A9MP (which are both different
+         * and valid configurations; we don't model A9UP).
+         */
+        set_feature(env, ARM_FEATURE_V7MP);
+        env->vfp.xregs[ARM_VFP_FPSID] = 0x41034000; /* Guess */
+        env->vfp.xregs[ARM_VFP_MVFR0] = 0x11110222;
+        env->vfp.xregs[ARM_VFP_MVFR1] = 0x01111111;
+        memcpy(env->cp15.c0_c1, cortexa9_cp15_c0_c1, 8 * sizeof(uint32_t));
+        memcpy(env->cp15.c0_c2, cortexa9_cp15_c0_c2, 8 * sizeof(uint32_t));
+        env->cp15.c0_cachetype = 0x80038003;
+        env->cp15.c0_clid = (1 << 27) | (1 << 24) | 3;
+        env->cp15.c0_ccsid[0] = 0xe00fe015; /* 16k L1 dcache. */
+        env->cp15.c0_ccsid[1] = 0x200fe015; /* 16k L1 icache. */
+        env->cp15.c1_sys = 0x00c50078;
+        break;
+		
     case ARM_CPUID_CORTEXM3:
         set_feature(env, ARM_FEATURE_V4T);
         set_feature(env, ARM_FEATURE_V5);

@@ -385,6 +415,7 @@ static const struct arm_cpu_t arm_cpu_names[] = {
     { ARM_CPUID_CORTEXM3, "cortex-m3"},
     { ARM_CPUID_CORTEXA8, "cortex-a8"},
     { ARM_CPUID_CORTEXA9, "cortex-a9"},
+    { ARM_CPUID_CORTEXA15, "cortex-a15"},
     { ARM_CPUID_TI925T, "ti925t" },
     { ARM_CPUID_PXA250, "pxa250" },
     { ARM_CPUID_SA1100,    "sa1100" },

1.7.1

Thanks for sending this; I have somewhat belatedly written up some comments on it.

I see the a15mpcore.c code is based on a version of mpcore.c which predates the MemoryRegion API changes -- we'll need to update it to use MemoryRegions.

There are some relics of 11MPCore peripherals lurking in there which need to be taken out. (I think we should probably clean up mpcore.c to separate out A9 from 11MPCore, incidentally.)

The vexpress A9 and A15 init functions can probably share code although I haven't looked too closely there.

For QEMU TCG we're going to want to model at least some of the cp15 registers (although probably mostly dummy implementations).

The A15 generic timer is accessed via cp15 registers rather than being memory mapped -- we need to decide which side of the KVM/QEMU boundary the model of that should live. (I'm guessing the right answer is "qemu side" which means we'll need an ABI between KVM and QEMU to pass (some) cp15 accesses through.)

thanks again
-- PMM

OK, I will make it updated.

Neither did I :)
Anyway I will dig the code harder.

I'm not focusing on this by now, if this a MUST, I will try to do it.

right!

Current arch timer implementation will first check whether arch timer is implemented *AND* whether arch timer frequency is set by security firmware.
If no arch timer available, SP804 will be used as clock source/event, that's what I am using so far.

If generic timer need to be supported, this will fall into QEMU side, with the help of KVM trapping any cp15 timer access. Anther issue is virtual timer support, I haven't make a clear picture how virtual timer hardware fit into KVM smoothly, so let's focus on what you proposed.

Anyway thanks for your suggestions, I will move on to next version to review :)

I am a slow learner
but I will keep trying to fight for my dreams!

--bill