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

[Alexander Graf]

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?

> - 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