public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Patrick Delaunay <patrick.delaunay@st.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 3/3] efi: update virtual address in efi_mem_carve_out
Date: Wed, 10 Apr 2019 11:02:59 +0200	[thread overview]
Message-ID: <1554886979-22890-3-git-send-email-patrick.delaunay@st.com> (raw)
In-Reply-To: <1554886979-22890-1-git-send-email-patrick.delaunay@st.com>

Handle virtual address in efi_mem_carve_out function
when a new region is created to avoid issue in EFI memory map.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---

Issue detected during test of test of UEFI on ev1/dk2 boards.

For debug purpose, I add the dump of the map in efi_mem_sort:

static void efi_mem_sort(void)
{
.....
	int i = 0;
	printf("-- %s -------------------\n", __func__ );
	list_for_each(lhandle, &efi_mem) {
		struct efi_mem_list *lmem;
		struct efi_mem_desc *cur;

		lmem = list_entry(lhandle, struct efi_mem_list, link);
		cur = &lmem->desc;

		printf("%02d: va %08x pa %08x size %08x (%04x pages) => va end %08x attribute = %llx type=%d\n",
			i++,
			(u32)cur->virtual_start,
			(u32)cur->physical_start,
			(u32)(cur->num_pages << EFI_PAGE_SHIFT),
			(u32)cur->num_pages,
			(u32) (cur->virtual_start + (cur->num_pages << EFI_PAGE_SHIFT)),
			cur->attribute,
			cur->type);
	}
}

I get the memory layout (for EV1):

00: va fcf87000 pa fff92000 size 0006e000 (006e pages) => va end fcff5000 attribute = 8 type=2
01: va fff91000 pa fff91000 size 00001000 (0001 pages) => va end fff92000 attribute = 8000000000000008 type=5
02: va fcf87000 pa fcf87000 size 0300a000 (300a pages) => va end fff91000 attribute = 8 type=2
03: va fcf86000 pa fcf86000 size 00001000 (0001 pages) => va end fcf87000 attribute = 8000000000000008 type=6
04: va fcf46000 pa fcf7d000 size 00009000 (0009 pages) => va end fcf4f000 attribute = 8 type=0
05: va fcf7c000 pa fcf7c000 size 00001000 (0001 pages) => va end fcf7d000 attribute = 8000000000000008 type=6
06: va fcf46000 pa fcf77000 size 00005000 (0005 pages) => va end fcf4b000 attribute = 8 type=0
07: va c0000000 pa c0000000 size 3cf77000 (3cf77 pages) => va end fcf77000 attribute = 8 type=7

But for some region virtual address (va) != physical address (pa)

After check of the code, the virtual address is not correctly managed
when new region is created.

I don't sure that could be a issue, but I solve the issue
with the proposed patch:

00: va fff92000 pa fff92000 size 0006e000 (006e pages) => va end 00000000 attribute = 8 type=2
01: va fff91000 pa fff91000 size 00001000 (0001 pages) => va end fff92000 attribute = 8000000000000008 type=5
02: va fcf87000 pa fcf87000 size 0300a000 (300a pages) => va end fff91000 attribute = 8 type=2
03: va fcf86000 pa fcf86000 size 00001000 (0001 pages) => va end fcf87000 attribute = 8000000000000008 type=6
04: va fcf7d000 pa fcf7d000 size 00009000 (0009 pages) => va end fcf86000 attribute = 8 type=0
05: va fcf7c000 pa fcf7c000 size 00001000 (0001 pages) => va end fcf7d000 attribute = 8000000000000008 type=6
06: va fcf77000 pa fcf77000 size 00005000 (0005 pages) => va end fcf7c000 attribute = 8 type=0
07: va c0000000 pa c0000000 size 3cf77000 (3cf77 pages) => va end fcf77000 attribute = 8 type=7

The virtual address are now correct.

PS: I don't found more elegant code to update the virtual address
    but I avoid to force virtual_address = physical address
    in this function.

 lib/efi_loader/efi_memory.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 81dc5fc..a47adef 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -168,6 +168,16 @@ static s64 efi_mem_carve_out(struct efi_mem_list *map,
 			free(map);
 		} else {
 			map->desc.physical_start = carve_end;
+			if (carve_end == map_end)
+				map->desc.virtual_start =
+					map_desc->virtual_start +
+					(map_desc->num_pages << EFI_PAGE_SHIFT);
+			else
+				map->desc.virtual_start =
+					carve_desc->virtual_start +
+					(carve_desc->num_pages <<
+					 EFI_PAGE_SHIFT);
+
 			map->desc.num_pages = (map_end - carve_end)
 					      >> EFI_PAGE_SHIFT;
 		}
@@ -186,6 +196,11 @@ static s64 efi_mem_carve_out(struct efi_mem_list *map,
 	newmap = calloc(1, sizeof(*newmap));
 	newmap->desc = map->desc;
 	newmap->desc.physical_start = carve_start;
+	if (carve_start == map_start)
+		newmap->desc.virtual_start = map_desc->virtual_start;
+	else
+		newmap->desc.virtual_start = carve_desc->virtual_start;
+
 	newmap->desc.num_pages = (map_end - carve_start) >> EFI_PAGE_SHIFT;
 	/* Insert before current entry (descending address order) */
 	list_add_tail(&newmap->link, &map->link);
-- 
2.7.4

  parent reply	other threads:[~2019-04-10  9:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-10  9:02 [U-Boot] [PATCH 1/3] efi: fix issue for 32bit targets with ram_top at 4G Patrick Delaunay
2019-04-10  9:02 ` [U-Boot] [PATCH 2/3] efi: add protection for block_dev Patrick Delaunay
2019-04-10 17:42   ` Heinrich Schuchardt
2019-04-11  9:30     ` Patrick DELAUNAY
2019-04-11 17:26   ` Heinrich Schuchardt
2019-04-10  9:02 ` Patrick Delaunay [this message]
2019-04-11 18:12   ` [U-Boot] [PATCH 3/3] efi: update virtual address in efi_mem_carve_out Heinrich Schuchardt
2019-04-10 16:40 ` [U-Boot] [PATCH 1/3] efi: fix issue for 32bit targets with ram_top at 4G Patrick Wildt
2019-04-11  8:03   ` Patrick DELAUNAY

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1554886979-22890-3-git-send-email-patrick.delaunay@st.com \
    --to=patrick.delaunay@st.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox