Hi Vitaly, On 2017-02-03 14:57, Vitaly Andrianov wrote: > Hello, > > I'm working on Jailhouse support for TI AM572x SOC (2 A15 cores). So > Linux running as a root cell on the CORE 0 and on another core I run a > bare-metal application. As far as MMU is disabled application can enable > I-cache only. And I tested that it works reasonably fast if running on > the CORE 1 w/o enabling hyper-visor (I loaded the application through > JTAG and ran). If I run this application as an inmate it works several > times slower. I checked the I-cache is enabled, but likes like it > doesn't help. > > Does anybody know why is that?
There are two possible reasons: - Virtualization and/or how Jailhouse uses it defeats the enabling of the I-cache - I would have to dig into the nasty details again to rule this out. - Something else slows things down so much that the I-cache cannot save your day - did you check the vmexit stats of your inmate? That said, I once had some hack to enable MMU and all caches for the inmates. But it was actually counter-productive, at least for the latency test. Historic fragments below (may no longer apply). Jan ----8<---- >From 7d01e57ffc40a5343d6f8de5e4c51084f8fdd775 Mon Sep 17 00:00:00 2001 From: Jan Kiszka <[email protected]> Date: Mon, 25 Jul 2016 08:03:23 +0200 Subject: [PATCH] inmates: arm: Enable caches during startup --- inmates/lib/arm/header.S | 28 ++++++++++++++++++++++++++++ inmates/tools/arm/linux-loader.c | 14 ++++++++++++++ 2 files changed, 42 insertions(+) diff --git a/inmates/lib/arm/header.S b/inmates/lib/arm/header.S index 72631cf..3fec45c 100644 --- a/inmates/lib/arm/header.S +++ b/inmates/lib/arm/header.S @@ -43,6 +43,18 @@ __reset_entry: ldr r0, =vectors mcr p15, 0, r0, c12, c0, 0 @ VBAR + ldr r0, =l1tab + mcr p15, 0, r0, c2, c0, 0 @ TTBR0 + + mov r0, #0x3500 @ T0SZ=0, IRGN0=ORGN0=1, SH0=3 + movt r0, #0x8000 @ EAE + mcr p15, 0, r0, c2, c0, 2 @ TTBCR + + mrc p15, 0, r0, c1, c0, 0 @ read SCTLR + orr r0, #0x5000 @ use round-robin, enable I cache + orr r0, #0x0005 @ enable data+unified caches and MMU + mcr p15, 0, r0, c1, c0, 0 @ write SCTLR + mov r0, #0 ldr r1, =bss_start ldr r2, =bss_dwords @@ -56,3 +68,19 @@ __reset_entry: b inmate_main .ltorg + + .section ".rodata" + + .align 12 +l1tab: + .word l2tab + 0x3, 0 @ valid, table + .quad 0x40000745 @ valid, EL0, RW, IS, access, device + + .align 12 +l2tab: + .quad 0x741 @ valid, EL0, RW, IS, access, WBRAWA +base=0x200000 +.rept 511 + .quad base + 0x745 @ valid, EL0, RW, IS, access, device + base=base+0x200000 +.endr diff --git a/inmates/tools/arm/linux-loader.c b/inmates/tools/arm/linux-loader.c index 53d2aab..6dadb70 100644 --- a/inmates/tools/arm/linux-loader.c +++ b/inmates/tools/arm/linux-loader.c @@ -14,6 +14,8 @@ #include <inmate.h> +#define SCTLR_C_BIT (1 << 2) + /* * Example memory map: * 0x00000000 this binary @@ -28,6 +30,7 @@ void inmate_main(void) { void register (*entry)(unsigned long, unsigned long, unsigned long); unsigned long register dtb; + u32 sctlr; printk("\nJailhouse ARM Linux bootloader\n"); @@ -44,5 +47,16 @@ void inmate_main(void) printk("DTB: 0x%08lx\n", dtb); printk("Image: 0x%08lx\n", entry); + /* + * Turn d-cache off again, as mandated by Linux boot process. + * We don't have any relevant data pending there, and Linux will + * invalidate the content before re-enabling it. + */ + asm volatile ( + "mrc p15, 0, %0, c1, c0, 0\n\t" + "orr %0, %1\n\t" + "mcr p15, 0, %0, c1, c0, 0\n\t" + : "=r" (sctlr) : "i" (SCTLR_C_BIT)); + entry(0, -1, dtb); } -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
