[U-Boot] [PATCH v4 21/21] efi_loader: Expose U-Boot addresses in memory map for sandbox

[Simon Glass]

Hi Alex,

On 23 June 2018 at 00:57, Alexander Graf <agraf at suse.de> wrote:
> Hi Simon,
>
> Am 23.06.2018 um 06:01 schrieb Simon Glass <sjg at chromium.org>:
>
> Hi Alex,
>
> On 18 June 2018 at 09:23, Alexander Graf <agraf at suse.de> wrote:
>
> We currently expose host addresses in the EFI memory map. That can be
>
> bad if we ever want to use sandbox to boot strap a real kernel, because
>
> then the kernel would fetch its memory table from our host virtual address
>
> map. But to make that use case work, we would need to have full control
>
> over the address space the EFI application sees.
>
>
> So let's expose only U-Boot addresses to the guest until we get to the
>
> point of allocation. EFI's allocation functions are fun - they can take
>
> U-Boot addresses as input values for hints and return host addresses as
>
> allocation results through the same uint64_t * parameter. So we need to
>
> be extra careful on what to pass in when.
>
>
> With this patch I am successfully able to run the efi selftest suite as
>
> well as grub.efi on aarch64.
>
>
> Signed-off-by: Alexander Graf <agraf at suse.de>
>
> ---
>
> arch/sandbox/cpu/cpu.c      | 19 -------------------
>
> lib/efi_loader/efi_memory.c | 12 ++++++------
>
> 2 files changed, 6 insertions(+), 25 deletions(-)
>
>
> Can you please point me to your latest series? I think you have
> decided to work on this yourself and pick bits from my series that you
> like.
>
>
> Believe me, I also picked things that I don't like. But ultimately sandbox
> is your court while efi_loader is mine. And I'm fairly sure both of us have
> better things to do than to run in circles.
>
> This I consider unpleasant behaviour for a maintainer, but
> ultimately I'm more interested in getting things resolved than any
> procedural issues. Please don't do this to anyone else, though, in the
> U-Boot community.
>
>
> I don't see the problem - it's pretty common in the Linux world. You propose
> something, I counterpropose, we converge, maintainer decides what to pick
> up.

This is certainly not Linux and I like to think we have a kinder and
more supportive environment here. I very seldom call out people on
this list for language and behaviour.

Also you are a maintainer, not another contributor.

>
> Anyway, at present I'm not sure what state it is in, so please point
> me to your latest tree so I can take a look and figure out what has
> actually changed from my v9 series.
>
>
> The current tree with v5 applied is here:
>
> https://github.com/agraf/u-boot/tree/efi-sandbox-v5
>
> Branch efi-next at the same location is the base for v5.

OK well at this stage I'm going to leave it in your hands as I've lost
track of all the patches and have no desire to send a v10 series.

Once everything lands I'll take a look and see if I think anything is
missing. Hopefully we can get sandbox EFi support into master when the
merge window opens.

Regards,
Simon