[PATCH 2/2] ARM: OMAP5: Add HYP mode entry support for secondary CPUs

[Santosh Shilimkar]

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 at ti.com> 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 at arm.com>
>>>> Cc: Christoffer Dall <christoffer.dall at linaro.org>
>>>> Cc: Tony Lindgren <tony at atomide.com>
>>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
>>>> ---
>>>>  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.