[U-Boot] [PATCH 00/11] sandbox: efi_loader support

[U-Boot] [PATCH 00/11] sandbox: efi_loader support

[Alexander Graf]

This patch set augments Simon's patch set for efi_loader support
in sandbox[1], but follows a different memory allocation scheme.

Instead of keeping U-Boot (physical) addresses in the EFI memory
map, this patch set makes the EFI memory map contain host virtual
(virtual) addresses. That way most logic "just works" and all EFI
interfaces automatically gain sandbox awareness.

With this patch set in place, I can run a good chunk of the selftest
suite as well as efi binaries compiled using gnu-efi.

Alex

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=49832

Alexander Graf (7):
  efi_loader: Use compiler constants for image loader
  efi_loader: Use map_sysmem() in bootefi command
  efi.h: Do not use config options
  efi_loader: Allow SMBIOS tables in highmem
  sandbox: Map host memory for efi_loader
  efi_loader: Disable miniapps on sandbox
  efi_loader: Pass virtual address to fs_read()

Heinrich Schuchardt (1):
  efi_loader: efi_allocate_pages is too restrictive

Simon Glass (3):
  efi: sandbox: Add distroboot support
  efi: sandbox: Add relocation constants
  efi: sandbox: Enable EFI loader for sandbox

 arch/sandbox/cpu/cpu.c            | 16 ++++++++++++++++
 cmd/bootefi.c                     | 13 ++++++++-----
 include/config_distro_bootcmd.h   | 13 +++++++++++++
 include/efi.h                     | 17 ++++-------------
 lib/efi/Makefile                  |  4 ++--
 lib/efi_loader/Kconfig            |  2 +-
 lib/efi_loader/efi_file.c         |  4 +++-
 lib/efi_loader/efi_image_loader.c | 12 ++++++------
 lib/efi_loader/efi_memory.c       |  2 +-
 lib/efi_loader/efi_runtime.c      | 12 ++++++++++++
 lib/efi_loader/efi_smbios.c       | 11 +++++++++--
 lib/efi_selftest/Makefile         |  2 +-
 12 files changed, 76 insertions(+), 32 deletions(-)

-- 
2.12.3

[U-Boot] [PATCH 01/11] efi: sandbox: Add distroboot support

[Alexander Graf]

From: Simon Glass <sjg@chromium.org>

With sandbox these values depend on the host system. Let's assume that it
is x86_64 for now.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
 include/config_distro_bootcmd.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index d672e8ebe6..1bd79ae3b8 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -251,6 +251,8 @@
 #elif defined(CONFIG_ARM)
 #define BOOTENV_EFI_PXE_ARCH "0xa"
 #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00010:UNDI:003000"
+
+/* For sandbox we only support 64-bit x86 at present */
 #elif defined(CONFIG_X86)
 /* Always assume we're running 64bit */
 #define BOOTENV_EFI_PXE_ARCH "0x7"
@@ -261,6 +263,17 @@
 #elif defined(CONFIG_CPU_RISCV_64)
 #define BOOTENV_EFI_PXE_ARCH "0x1b"
 #define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00027:UNDI:003000"
+#elif defined(CONFIG_SANDBOX)
+/*
+ * TODO(sjg at chromium.org): Consider providing a way to enable sandbox features
+ * based on the host architecture
+ */
+# ifndef __x86_64__
+#  warning "sandbox EFI support is only tested on 64-bit x86"
+# endif
+/* To support other *host* architectures this should be changed */
+#define BOOTENV_EFI_PXE_ARCH "0x7"
+#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00007:UNDI:003000"
 #else
 #error Please specify an EFI client identifier
 #endif
-- 
2.12.3

[U-Boot] [PATCH 02/11] efi: sandbox: Add relocation constants

[Alexander Graf]

From: Simon Glass <sjg@chromium.org>

Add these so that we can build the EFI loader for sandbox. The values are
for x86_64 so potentially bogus. But we don't support relocation within
sandbox anyway.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
 lib/efi_loader/efi_runtime.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 4874eb602f..388dfb9840 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -62,6 +62,18 @@ struct dyn_sym {
 #define R_ABSOLUTE	R_RISCV_64
 #define SYM_INDEX	32
 #endif
+
+/* For sandbox we only support 64-bit x86 at present */
+#elif defined(CONFIG_SANDBOX)
+/*
+ * TODO(sjg at chromium.org): Consider providing a way to enable sandbox features
+ * based on the host architecture
+ */
+# ifndef __x86_64__
+#  warning "sandbox EFI support is only tested on 64-bit x86"
+# endif
+#define R_RELATIVE	8
+#define R_MASK		0xffffffffULL
 #else
 #error Need to add relocation awareness
 #endif
-- 
2.12.3

[U-Boot] [PATCH 03/11] efi_loader: Use compiler constants for image loader

[Alexander Graf]

The EFI image loader tries to determine which target architecture we're
working with to only load PE binaries that match.

So far this has worked based on CONFIG defines, because the target CPU
was always indicated by a config define. With sandbox however, this is
not longer true as all sandbox targets only encompass a single CONFIG
option and so we need to use compiler defines to determine the CPU
architecture.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 lib/efi_loader/efi_image_loader.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/lib/efi_loader/efi_image_loader.c b/lib/efi_loader/efi_image_loader.c
index ecdb77e5b6..fdf40a62c8 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -19,25 +19,25 @@ const efi_guid_t efi_simple_file_system_protocol_guid =
 const efi_guid_t efi_file_info_guid = EFI_FILE_INFO_GUID;
 
 static int machines[] = {
-#if defined(CONFIG_ARM64)
+#if defined(__aarch64__)
 	IMAGE_FILE_MACHINE_ARM64,
-#elif defined(CONFIG_ARM)
+#elif defined(__arm__)
 	IMAGE_FILE_MACHINE_ARM,
 	IMAGE_FILE_MACHINE_THUMB,
 	IMAGE_FILE_MACHINE_ARMNT,
 #endif
 
-#if defined(CONFIG_X86_64)
+#if defined(__x86_64__)
 	IMAGE_FILE_MACHINE_AMD64,
-#elif defined(CONFIG_X86)
+#elif defined(__i386__)
 	IMAGE_FILE_MACHINE_I386,
 #endif
 
-#if defined(CONFIG_CPU_RISCV_32)
+#if defined(__riscv) && (__riscv_xlen == 32)
 	IMAGE_FILE_MACHINE_RISCV32,
 #endif
 
-#if defined(CONFIG_CPU_RISCV_64)
+#if defined(__riscv) && (__riscv_xlen == 64)
 	IMAGE_FILE_MACHINE_RISCV64,
 #endif
 	0 };
-- 
2.12.3

[U-Boot] [PATCH 04/11] efi_loader: Use map_sysmem() in bootefi command

[Alexander Graf]

The bootefi command gets a few addresses as values passed in. In sandbox,
these values are in U-Boot address space, so we need to make sure we
explicitly call map_sysmem() on them to be able to access them.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 cmd/bootefi.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index f55a40dc84..a86a2bd4a9 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -14,6 +14,7 @@
 #include <errno.h>
 #include <linux/libfdt.h>
 #include <linux/libfdt_env.h>
+#include <mapmem.h>
 #include <memalign.h>
 #include <asm/global_data.h>
 #include <asm-generic/sections.h>
@@ -389,7 +390,8 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 	unsigned long addr;
 	char *saddr;
 	efi_status_t r;
-	void *fdt_addr;
+	unsigned long fdt_addr;
+	void *fdt;
 
 	/* Allow unaligned memory access */
 	allow_unaligned();
@@ -406,11 +408,12 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 		return CMD_RET_USAGE;
 
 	if (argc > 2) {
-		fdt_addr = (void *)simple_strtoul(argv[2], NULL, 16);
+		fdt_addr = simple_strtoul(argv[2], NULL, 16);
 		if (!fdt_addr && *argv[2] != '0')
 			return CMD_RET_USAGE;
 		/* Install device tree */
-		r = efi_install_fdt(fdt_addr);
+		fdt = map_sysmem(fdt_addr, 0);
+		r = efi_install_fdt(fdt);
 		if (r != EFI_SUCCESS) {
 			printf("ERROR: failed to install device tree\n");
 			return CMD_RET_FAILURE;
@@ -429,7 +432,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 			addr = simple_strtoul(saddr, NULL, 16);
 		else
 			addr = CONFIG_SYS_LOAD_ADDR;
-		memcpy((char *)addr, __efi_helloworld_begin, size);
+		memcpy(map_sysmem(addr, size), __efi_helloworld_begin, size);
 	} else
 #endif
 #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
@@ -475,7 +478,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 	}
 
 	printf("## Starting EFI application at %08lx ...\n", addr);
-	r = do_bootefi_exec((void *)addr, bootefi_device_path,
+	r = do_bootefi_exec(map_sysmem(addr, 0), bootefi_device_path,
 			    bootefi_image_path);
 	printf("## Application terminated, r = %lu\n",
 	       r & ~EFI_ERROR_MASK);
-- 
2.12.3

[U-Boot] [PATCH 05/11] efi.h: Do not use config options

[Alexander Graf]

Currently efi.h determines a few bits of its environment according to
config options. This falls apart with the efi stub support which may
result in efi.h getting pulled into the stub as well as real U-Boot
code. In that case, one may be 32bit while the other one is 64bit.

This patch changes the conditionals to use compiler provided defines
instead. That way we always adhere to the build environment we're in
and the definitions adjust automatically.

Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
 include/efi.h    | 17 ++++-------------
 lib/efi/Makefile |  4 ++--
 2 files changed, 6 insertions(+), 15 deletions(-)

diff --git a/include/efi.h b/include/efi.h
index e30a3c51c6..826d484977 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -19,12 +19,12 @@
 #include <linux/string.h>
 #include <linux/types.h>
 
-#if CONFIG_EFI_STUB_64BIT || (!defined(CONFIG_EFI_STUB) && defined(__x86_64__))
-/* EFI uses the Microsoft ABI which is not the default for GCC */
+/* EFI on x86_64 uses the Microsoft ABI which is not the default for GCC */
+#ifdef __x86_64__
 #define EFIAPI __attribute__((ms_abi))
 #else
 #define EFIAPI asmlinkage
-#endif
+#endif /* __x86_64__ */
 
 struct efi_device_path;
 
@@ -32,16 +32,7 @@ typedef struct {
 	u8 b[16];
 } efi_guid_t;
 
-#define EFI_BITS_PER_LONG	BITS_PER_LONG
-
-/*
- * With 64-bit EFI stub, EFI_BITS_PER_LONG has to be 64. EFI_STUB is set
- * in lib/efi/Makefile, when building the stub.
- */
-#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB)
-#undef EFI_BITS_PER_LONG
-#define EFI_BITS_PER_LONG	64
-#endif
+#define EFI_BITS_PER_LONG	(sizeof(long) * 8)
 
 /* Bit mask for EFI status code with error */
 #define EFI_ERROR_MASK (1UL << (EFI_BITS_PER_LONG - 1))
diff --git a/lib/efi/Makefile b/lib/efi/Makefile
index 18d081ac46..ece7907227 100644
--- a/lib/efi/Makefile
+++ b/lib/efi/Makefile
@@ -7,9 +7,9 @@ obj-$(CONFIG_EFI_STUB) += efi_info.o
 
 CFLAGS_REMOVE_efi_stub.o := -mregparm=3 \
 	$(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32)
-CFLAGS_efi_stub.o := -fpic -fshort-wchar -DEFI_STUB
+CFLAGS_efi_stub.o := -fpic -fshort-wchar
 CFLAGS_REMOVE_efi.o := -mregparm=3 \
 	$(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32)
-CFLAGS_efi.o := -fpic -fshort-wchar -DEFI_STUB
+CFLAGS_efi.o := -fpic -fshort-wchar
 
 extra-$(CONFIG_EFI_STUB) += efi_stub.o efi.o
-- 
2.12.3

[U-Boot] [PATCH 06/11] efi_loader: Allow SMBIOS tables in highmem

[Alexander Graf]

We try hard to make sure that SMBIOS tables live in the lower 32bit.
However, when we can not find any space at all there, we should not
error out but instead just fall back to map them in the full address
space instead.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 lib/efi_loader/efi_smbios.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c
index 7c3fc8af0b..932f7582ec 100644
--- a/lib/efi_loader/efi_smbios.c
+++ b/lib/efi_loader/efi_smbios.c
@@ -26,8 +26,15 @@ efi_status_t efi_smbios_register(void)
 	/* Reserve 4kiB page for SMBIOS */
 	ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
 				 EFI_RUNTIME_SERVICES_DATA, 1, &dmi);
-	if (ret != EFI_SUCCESS)
-		return ret;
+
+	if (ret != EFI_SUCCESS) {
+		/* Could not find space in lowmem, use highmem instead */
+		ret = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES,
+					 EFI_RUNTIME_SERVICES_DATA, 1, &dmi);
+
+		if (ret != EFI_SUCCESS)
+			return ret;
+	}
 
 	/*
 	 * Generate SMBIOS tables - we know that efi_allocate_pages() returns
-- 
2.12.3

[U-Boot] [PATCH 07/11] sandbox: Map host memory for efi_loader

[Alexander Graf]

With efi_loader we do not control payload applications, so we can not
teach them about the difference between virtual and physical addresses.

Instead, let's just always map host virtual addresses in the efi memory
map. That way we can be sure that all memory allocation functions always
return consumable pointers.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/sandbox/cpu/cpu.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index cde0b055a6..b4f1e22cb2 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -5,6 +5,7 @@
 #define DEBUG
 #include <common.h>
 #include <dm.h>
+#include <efi_loader.h>
 #include <errno.h>
 #include <linux/libfdt.h>
 #include <os.h>
@@ -177,3 +178,18 @@ void longjmp(jmp_buf jmp, int ret)
 	while (1)
 		;
 }
+
+/*
+ * In sandbox, we don't have a 1:1 map, so we need to expose
+ * process addresses instead of U-Boot addresses
+ */
+void efi_add_known_memory(void)
+{
+	u64 ram_start = (uintptr_t)map_sysmem(0, gd->ram_size);
+	u64 ram_size = gd->ram_size;
+	u64 start = (ram_start + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
+	u64 pages = (ram_size + EFI_PAGE_MASK) >> EFI_PAGE_SHIFT;
+
+	efi_add_memory_map(start, pages, EFI_CONVENTIONAL_MEMORY,
+			   false);
+}
-- 
2.12.3

[U-Boot] [PATCH 08/11] efi_loader: efi_allocate_pages is too restrictive

[Alexander Graf]

From: Heinrich Schuchardt <xypron.glpk@gmx.de>

When running on the sandbox the stack is not necessarily at a higher memory
address than the highest free memory.

There is no reason why the checking of the highest memory address should be
more restrictive for EFI_ALLOCATE_ANY_PAGES than for
EFI_ALLOCATE_MAX_ADDRESS.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
[agraf: use -1ULL instead]
Signed-off-by: Alexander Graf <agraf@suse.de>
---
 lib/efi_loader/efi_memory.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index ec66af98ea..ce29bcc6a3 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -295,7 +295,7 @@ efi_status_t efi_allocate_pages(int type, int memory_type,
 	switch (type) {
 	case EFI_ALLOCATE_ANY_PAGES:
 		/* Any page */
-		addr = efi_find_free_memory(len, gd->start_addr_sp);
+		addr = efi_find_free_memory(len, -1ULL);
 		if (!addr) {
 			r = EFI_NOT_FOUND;
 			break;
-- 
2.12.3

[U-Boot] [PATCH 09/11] efi_loader: Disable miniapps on sandbox

[Alexander Graf]

In the sandbox environment we can not easily build efi stub binaries
right now, so let's disable the respective test cases for the efi
selftest suite.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 lib/efi_selftest/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
index 4fe404d88d..bf5c8199cb 100644
--- a/lib/efi_selftest/Makefile
+++ b/lib/efi_selftest/Makefile
@@ -41,7 +41,7 @@ endif
 
 # TODO: As of v2018.01 the relocation code for the EFI application cannot
 # be built on x86_64.
-ifeq ($(CONFIG_X86_64),)
+ifeq ($(CONFIG_X86_64)$(CONFIG_SANDBOX),)
 
 ifneq ($(CONFIG_CMD_BOOTEFI_SELFTEST),)
 
-- 
2.12.3

[U-Boot] [PATCH 10/11] efi_loader: Pass virtual address to fs_read()

[Alexander Graf]

The fs_read() function wants to get a virtual (u-boot address space
in sandbox) address rather than a physical (host address space in
sandbox) one.

So let's convert from the real pointer back a the physical address
to make efi_loader on sandbox happier.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 lib/efi_loader/efi_file.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index e6a15bcb52..ecf174a3dd 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -232,8 +232,10 @@ static efi_status_t file_read(struct file_handle *fh, u64 *buffer_size,
 		void *buffer)
 {
 	loff_t actread;
+	/* fs_read expects buffer as virtual address */
+	uintptr_t buffer_addr = (uintptr_t)map_to_sysmem((uintptr_t)buffer);
 
-	if (fs_read(fh->path, (ulong)buffer, fh->offset,
+	if (fs_read(fh->path, buffer_addr, fh->offset,
 		    *buffer_size, &actread))
 		return EFI_DEVICE_ERROR;
 
-- 
2.12.3

[U-Boot] [PATCH 10/11] efi_loader: Pass virtual address to fs_read()

[Simon Glass]

Hi Alex,

On 14 June 2018 at 10:33, Alexander Graf <agraf@suse.de> wrote:
> The fs_read() function wants to get a virtual (u-boot address space
> in sandbox) address rather than a physical (host address space in
> sandbox) one.
>

The terminology is wrong here. It is not about virtual and physical
addresses - that's an MMU concept.

It's about sandbox using a special memory buffer to emulate U-Boot
memory access.

The code is correct but the comment and commit message will cause
great confusion, so please fix.

It is document in a few READMEs, but perhaps I should add some
comments to mapmem.h ?

Regards,
Simon

[U-Boot] [PATCH 11/11] efi: sandbox: Enable EFI loader for sandbox

[Alexander Graf]

From: Simon Glass <sjg@chromium.org>

This allows this feature to build within sandbox. This is for testing
purposes only since it is not possible for sandbox to load native code.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
 lib/efi_loader/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index df58e633d1..d471e6f4a4 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -1,6 +1,6 @@
 config EFI_LOADER
 	bool "Support running EFI Applications in U-Boot"
-	depends on (ARM || X86 || RISCV) && OF_LIBFDT
+	depends on (ARM || X86 || RISCV || SANDBOX) && OF_LIBFDT
 	# We do not support bootefi booting ARMv7 in non-secure mode
 	depends on !ARMV7_NONSEC
 	# We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB
-- 
2.12.3

[U-Boot] [PATCH 00/11] sandbox: efi_loader support

[Simon Glass]

Hi,

On 14 June 2018 at 10:33, Alexander Graf <agraf@suse.de> wrote:
> This patch set augments Simon's patch set for efi_loader support
> in sandbox[1], but follows a different memory allocation scheme.
>
> Instead of keeping U-Boot (physical) addresses in the EFI memory
> map, this patch set makes the EFI memory map contain host virtual
> (virtual) addresses. That way most logic "just works" and all EFI
> interfaces automatically gain sandbox awareness.
>
> With this patch set in place, I can run a good chunk of the selftest
> suite as well as efi binaries compiled using gnu-efi.

Can you rebase this on top of my series? You seem to have picked up
only a few patches from my series. Ideally I'd like to get those
applied so that sandbox works, and then do future work on top of that.

Regards,
Simon

[U-Boot] [PATCH 00/11] sandbox: efi_loader support

[Alexander Graf]

On 06/14/2018 06:55 PM, Simon Glass wrote:
> Hi,
>
> On 14 June 2018 at 10:33, Alexander Graf <agraf@suse.de> wrote:
>> This patch set augments Simon's patch set for efi_loader support
>> in sandbox[1], but follows a different memory allocation scheme.
>>
>> Instead of keeping U-Boot (physical) addresses in the EFI memory
>> map, this patch set makes the EFI memory map contain host virtual
>> (virtual) addresses. That way most logic "just works" and all EFI
>> interfaces automatically gain sandbox awareness.
>>
>> With this patch set in place, I can run a good chunk of the selftest
>> suite as well as efi binaries compiled using gnu-efi.
> Can you rebase this on top of my series? You seem to have picked up
> only a few patches from my series. Ideally I'd like to get those
> applied so that sandbox works, and then do future work on top of that.

I did that on purpose, yes. I omitted patches that we either don't need 
(like the smbios one, because we already call the helpers with pointers) 
or that I think move us into the wrong direction (like the one that 
calls map_sysmem() in the allocation path or the new bootefi test target 
where I would rather like to see the selftest target extended.


Alex