Re: [MULTIBOOT2 DOC PATCH v2 05/11] multiboot2: Add description of support for EFI boot services

From: Daniel Kiper <dkiper@net-space.pl>
To: tsoome@me.com, grub-devel@gnu.org
Cc: jgross@suse.com, eric.snowberg@oracle.com,
	Andrei Borzenkov <arvidjaar@gmail.com>,
	phcoder@gmail.com, seth.goldberg@oracle.com,
	andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org
Subject: Re: [MULTIBOOT2 DOC PATCH v2 05/11] multiboot2: Add description of support for EFI boot services
Date: Mon, 28 Nov 2016 16:46:57 +0100	[thread overview]
Message-ID: <20161128154657.GA1485__16847.3712787547$1480348084$gmane$org@router-fw-old.local.net-space.pl> (raw)
In-Reply-To: <BAA7C4EA-0E4D-4466-B9A0-2743D898DBE7@me.com>

Hi Toomas,

Thank you for comments.

On Thu, Nov 24, 2016 at 11:47:48PM +0200, Toomas Soome wrote:
> There is still the same confusion as with entry address tag 7; the diagram has

I suppose that you thought about tag type 3.

> u_virt, yet the text does claim it is physical address. Sure, it is assumed the
> identity mapping, but still those names are creating confusion.

If yes then I agree that u_virt should be changed to u_phys. Though maybe in
longterm we should define tags for every architecture separately with types
specific for a given architecture. Then we should avoid most of such confusions.
I hope...

> Moreover, the EFI32 and EFI64 have different address sizes (32 versus 64 bit),
> yet there is the same type: u_virt - so it hints the upper part of the 64bit
> address is ignored, but its not really clear from the text???

It is clear that it should be u_phys or u32 for EFI i386. Though I am not sure
about EFI amd64 right now. Potentially it could be u64. However, I assume (at
least right now; and current GRUB implementation works in that way) that the boot
loader cannot put any part of an image higher than 4 GiB - 1 (well, I agree that
it should be mentioned in spec). Even on EFI amd64 platform. This is because still
some of the image boot code can be executed in 32-bit mode. We have such situation
in Xen. So, from this point of view 32-bit entry_addr in tag type 9 is sufficient.
Though I can agree that we should anticipate support for full 64-bit images.
I think that it is possible (but not implemented yet). We should add to spec tag
which says: yes, I am 64-bit image. Then the image may provide relevant 64-bit
equivalent tags (defined properly in spec). So, in this case we should have in spec
another EFI amd64 tag which has 64-bit entry_addr. This way various boot code types
(32-bit and 64-bit) may coexist without any issue in one image and boot loader may
choose supported one. Does it make sense?

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel