On Monday 25 November 2013 11:42 AM, Marc Zyngier wrote: > On 25/11/13 16:28, Santosh Shilimkar wrote: >> On Monday 25 November 2013 10:09 AM, Christoffer Dall wrote: >>> On 23 November 2013 16:07, Santosh Shilimkar <santosh.shilimkar@xxxxxx> wrote: >>>> Boot-CPU entry into the HYP mode is managed in boot-loader but >>>> the secondary CPUs directly jumps to kernel during boot. Same >>>> path is also used for CPU hotplug as well during suspend for >>>> secondary CPU. >>>> >>>> Hence patch the secondary CPU boot path for hyp mode etry. >>>> >>>> Cc: Marc Zyngier <marc.zyngier@xxxxxxx> >>>> Cc: Christoffer Dall <christoffer.dall@xxxxxxxxxx> >>>> Cc: Tony Lindgren <tony@xxxxxxxxxxx> >>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx> >>>> --- >>>> arch/arm/mach-omap2/omap-headsmp.S | 7 +++++++ >>>> 1 file changed, 7 insertions(+) >>>> >>>> diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S >>>> index 75e9295..4844dd8 100644 >>>> --- a/arch/arm/mach-omap2/omap-headsmp.S >>>> +++ b/arch/arm/mach-omap2/omap-headsmp.S >>>> @@ -22,6 +22,7 @@ >>>> >>>> /* Physical address needed since MMU not enabled yet on secondary core */ >>>> #define AUX_CORE_BOOT0_PA 0x48281800 >>>> +#define API_HYP_ENTRY 0x102 >>>> >>>> /* >>>> * OMAP5 specific entry point for secondary CPU to jump from ROM >>>> @@ -38,6 +39,12 @@ wait: ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0 >>>> and r4, r4, #0x0f >>>> cmp r0, r4 >>>> bne wait >>>> +#ifdef CONFIG_KVM_ARM_HOST >>>> + ldr r12, =API_HYP_ENTRY >>>> + adr r0, hyp_boot >>>> + smc #0 >>>> +hyp_boot: >>>> +#endif >>>> b secondary_startup >>>> END(omap5_secondary_startup) >>>> /* >>> >>> hmm, this means that currently running this in a guest will fail to >>> bring-up SMP, right? >>> >> Nope. Because the code under 'KVM_ARM_HOST' macro. Guest build >> will not enable CONFIG_KVM_ARM_HOST and things should be fine then. >> Right ? > > Absolutely not. We're way past the "one image per usage" model, and I > fully expect the same kernel to boot both as a guest and a host. > Otherwise, multiplatform is just a joke. > >>> Couldn't you create a little wrapper-pen in U-Boot instead, which >>> replicates the omap boot protocol and takes care of the hyp-mode >>> startup there instead, keeping this completely out of the kernel? >>> >> Its not just booting but CPU hotplug also follows the same path >> so we need the mechanism in kernel to switch mode. >> >> In general, I think its important to consider the aspect with >> CPU PM. CPUs are not going to go through the boot-loaders in >> those paths and hence need of HYP entry in the kernel will >> be must. > > I definitely agree that you need to consider PM as well. But we've > decided a long time ago that we wouldn't take that kind of code in the > kernel. Your CPU has to reach the kernel in HYP, and that is down to > your boot protocol to take care off that. > > There are a few options. Christoffer mentioned having a pen, and you > also could implement PSCI fairly easily (I've recently posted a u-boot > patch series to take care of this, though there is still a fair bit of > work required). > > Whatever the approach is, the bottom line remains: your CPU enters the > kernel in HYP. > Our emails crossed. I understand the stand from you guys. Lets continue discussion on other thread. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
