[U-Boot] [RFC 1/1] efi_loader: refactor switch to hypervisor mode

[Heinrich Schuchardt]

On 12/26/18 8:42 AM, Alexander Graf wrote:
> 
> 
> On 26.12.18 03:02, Heinrich Schuchardt wrote:
>> On 12/25/18 1:39 PM, Mark Kettenis wrote:
>>>> From: Heinrich Schuchardt <xypron.glpk at gmx.de>
>>>> Date: Tue, 25 Dec 2018 09:26:57 +0100
>>>>
>>>> Refactor the switch from supervisor to hypervisor to a new function called at
>>>> the beginning of do_bootefi().
>>>>
>>>> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
>>>> ---
>>>> With this patch I am just moving around the switch from supervisor to
>>>> hypervisor mode within the EFI subsystem. Similar switching also occurs
>>>> in all other boot commands (cf. arch/arm/lib/bootm.c).
>>> Never been a huge fan of setjmp/longjmp, but I can see what you're
>>> doing here.  This is tricky code though, so I think this needs to be
>>> tested on armv7 systems that support virtualisation (Cortex-A7) and
>>> systems that don't (Cortex-A9).
>>
>> For
>>
>>>
>>>> Why are we running the U-Boot console in supervisor mode at all? Wouldn't
>>>> it be advisable for security reasons to switch to hypervisor mode before
>>>> entering the console?
>>> On some boards there are commands that access secure devices.  So
>>> those commands would no longer work.  Obviously that is already the
>>> case when an EFI payload returns to the U-Boot command prompt.
>>>
>>
>> Thanks Mark for pointing this out.
>>
>> We have some major differences between bootm and bootefi:
>>
>> - Bootefi does not support CONFIG_ARMV8_SWITCH_TO_EL1 used by some
>>   Xilinx boards.
> 
> Yeah, mostly because I really dislike boards that simply switch to EL1
> for no good reason ;).
> 
>> - It ignores CONFIG_ARMV8_PSCI.
> 
> What exactly should it honor here?

Call armv8_setup_psci() and possibly smp_kick_all_cpus().

Regards

Heinrich

> 
>> - Update_os_arch_secondary_cores() is not called (needed for preparing
>>   SMP on several NXP platforms). I think these are maintained by York.
>>
>> So uniting the code might be advisable.
> 
> Well, bootm assumes that there is a single big step from U-Boot into
> payload (exiting U-Boot). With UEFI we have this long phase in between
> where we're in UEFI land, but still need full access to all U-Boot
> device infrastructure.
> 
> So I'm not quite sure how to unify that easily.
> 
> 
> Alex
>