Re: HYP Kernel boot requirements

[Santosh Shilimkar <santosh.shilimkar@ti.com>]

On Tuesday 26 November 2013 12:37 PM, Dave Martin wrote:
> On Tue, Nov 26, 2013 at 09:47:13AM -0500, Santosh Shilimkar wrote:
>> On Tuesday 26 November 2013 09:13 AM, Catalin Marinas wrote:
>>> On Mon, Nov 25, 2013 at 07:44:08PM +0000, Santosh Shilimkar wrote:
>>>> On Monday 25 November 2013 12:28 PM, Catalin Marinas wrote:
>>>>> On Mon, Nov 25, 2013 at 04:59:16PM +0000, Santosh Shilimkar wrote:
>>>>>> What I am saying is the platforms like OMAP5 already support PM in
>>>>>> mainline kernel and we can't break that for KVM. Boot-loaders
>>>>>> would be thrashed after boot so you need something which runs
>>>>>> in Kernel or along with Kernel to have equivalent of hyp
>>>>>> switching.
>>>>>>
>>>>>> Am not challenging the agreed direction but we need to solve the
>>>>>> PM problem as well before making "all CPU runs boot-loader for
>>>>>> HYP kernels" as a must have. At least its is a change in boot
>>>>>> strategy from existing kernels.
>>>>>
>>>>> Of course I recommend PSCI which covers both hotplug and suspend ;), but
>>>>> I guess it's not the case for OMAP5. Since OMAP has its own secondary
>>>>> booting protocol and CPU hotplug re-entry, can you not just use
>>>>> different entry point when the primary CPU was initially started in Hyp
>>>>> mode (e.g. omap5_hyp_secondary_startup)?
>>>>>
>>>> How will that solve the guest secondary boot failure case when using
>>>> the same kernel binary for guest-boot ? Even for primary CPU which
>>>> will be suspended it needs to resume already in HYP mode and its not
>>>> going to go through boot-loader. So the low power code needs to have
>>>> HYP switch code so that CPU resumes in HYP mode.
>>>
>>> Is it late to rewrite the OMAP5 firmware?
>>>
>> Well its ROM'ed unfortunately so no choice. OMAP5 ROM did implement
>> a secure API which lets you enter into HYP mode and thats the only
>> thing can be used.
> 
> If the ROM is capable of loading some additional signed Secure World
> firmware after the ROM itself has booted, PSCI could be implemented
> in the second, resident firmware payload.
> 
> Some SoCs ship with boot ROMs that can do that -- is this not the case
> for OMAP5?
> 
On OMAP, the secure devices there is a way to do this but not for 
general purpose devices. General purpose devices once you
exit the ROM code, we exit out of security and only way to
re-enter secure word is via ROM implemented monitor/secure
APIs.

regards,
Santosh