[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MULTIBOOT2 DOC PATCH v2 05/11] multiboot2: Add description of suppo
From: |
Daniel Kiper |
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 |
User-agent: |
Mutt/1.3.28i |
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
- [MULTIBOOT2 DOC PATCH v2 00/10] multiboot2: Update documentation, Daniel Kiper, 2016/11/24
- [MULTIBOOT2 DOC PATCH v2 02/11] multiboot2: Replace redundant if with the, Daniel Kiper, 2016/11/24
- [MULTIBOOT2 DOC PATCH v2 01/11] multiboot2: Rename Multiboot to Multiboot2, Daniel Kiper, 2016/11/24
- [MULTIBOOT2 DOC PATCH v2 03/11] multiboot2: Clarify meaning of information request header tag, Daniel Kiper, 2016/11/24
- [MULTIBOOT2 DOC PATCH v2 04/11] multiboot2: Fix description of EFI boot services tag, Daniel Kiper, 2016/11/24
- [MULTIBOOT2 DOC PATCH v2 05/11] multiboot2: Add description of support for EFI boot services, Daniel Kiper, 2016/11/24
- Re: [MULTIBOOT2 DOC PATCH v2 05/11] multiboot2: Add description of support for EFI boot services, Andrei Borzenkov, 2016/11/28
[MULTIBOOT2 DOC PATCH v2 06/11] multiboot2: Add description of EFI image handle tags, Daniel Kiper, 2016/11/24
[MULTIBOOT2 DOC PATCH v2 07/11] multiboot2: Add description of support for relocatable images, Daniel Kiper, 2016/11/24