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

[Toomas Soome <tsoome@xxxxxx>]

> On 29. nov 2016, at 11:08, Daniel Kiper <dkiper@xxxxxxxxxxxx> wrote:
> 
> On Mon, Nov 28, 2016 at 08:53:51PM +0300, Andrei Borzenkov wrote:
>> 24.11.2016 23:40, Daniel Kiper ?????:
>>> Signed-off-by: Daniel Kiper <daniel.kiper@xxxxxxxxxx>
>>> ---
>>> v2 - suggestions/fixes:
>>>   - clarify physical address meaning for EFI amd64
>>>     mode with boot services enabled
>>>     (suggested by Andrew Cooper).
>>> ---
>>> doc/multiboot.texi |  115 
>>> +++++++++++++++++++++++++++++++++++++++++++++++++++-
>>> doc/multiboot2.h   |    2 +
>>> 2 files changed, 115 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/doc/multiboot.texi b/doc/multiboot.texi
>>> index f0f167e..cc1edab 100644
>>> --- a/doc/multiboot.texi
>>> +++ b/doc/multiboot.texi
>>> @@ -534,6 +534,66 @@ The physical address to which the boot loader should 
>>> jump in order to
>>> start running the operating system.
>>> @end table
>>> 
>>> +@subsection EFI i386 entry address tag of Multiboot2 header
>>> +
>>> +@example
>>> +@group
>>> +        +-------------------+
>>> +u16     | type = 8          |
>>> +u16     | flags             |
>>> +u32     | size              |
>>> +u_virt  | entry_addr        |
>>> +        +-------------------+
>>> +@end group
>>> +@end example
>>> +
>>> +All of the address fields in this tag are physical addresses.
>> 
>> Should not entry_addr be u_phys then? Otherwise what is exact difference
> 
> Please look at my earlier email to Toomas.
> 
>> between u_phys and u_virt? Also for type == 3?
> 
> Short excerpt from multiboot.texi:
> 
> @item u_phys
> The type of unsigned data of the same size as target architecture
> physical address size.
> 
> @item u_virt
> The type of unsigned data of the same size as target architecture
> virtual address size.
> 
> Anyway, I agree that entry_addr type should be changed here.


Just to give an example about the scale of the mess here…

We boot BIOS system and get 32bit addresses as grub is running in 32bit 
protected mode.
We boot UEFI32, and get 32bit addresses.
We boot UEFI64, and get 64bit addresses.

Now, what is “target architecture physical/virtual address size” in case we 
start 64bit kernel from UEFI32? (or from BIOS for that matter). Also in fact, 
the grub2 itself is *not* using this “target architecture address size”, but is 
explicitly using multiboot_uint32_t - which from practical point of view seems 
to work out just fine, but does not match at all with documentation.

So, suppose I need to review and verify the implementation… ;)

just my 2cents,
toomas


> 
>>> +The meaning of each is as follows:
>>> +
>>> +@table @code
>>> +
>>> +@item entry_addr
>>> +The physical address to which the boot loader should jump in order to
>>> +start running EFI i386 compatible operating system code.
>>> +@end table
>>> +
>>> +This tag is taken into account only on EFI i386 platforms
>>> +when Multiboot2 image header contains EFI boot services tag.
>>> +Then entry point specified in ELF header and the entry address
>>> +tag of Multiboot2 header are ignored.
>>> +
>>> +@subsection EFI amd64 entry address tag of Multiboot2 header
>>> +
>>> +@example
>>> +@group
>>> +        +-------------------+
>>> +u16     | type = 9          |
>>> +u16     | flags             |
>>> +u32     | size              |
>>> +u_virt  | entry_addr        |
>>> +        +-------------------+
>>> +@end group
>>> +@end example
>>> +
>>> +All of the address fields in this tag are physical addresses (paging
>>> +mode is enabled and any memory space defined by the UEFI memory map
>>> +is identity mapped, hence, virtual address equals physical address;
>> 
>> Same here; it is confusing marking field as u_virt and describing it
>> immediately as "physical address".
> 
> Ditto.
> 
>>> +Unified Extensible Firmware Interface Specification, Version 2.6,
>>> +section 2.3.4, x64 Platforms, boot services). The meaning of each
>>> +is as follows:
>>> +
>>> +@table @code
>>> +
>>> +@item entry_addr
>>> +The physical address to which the boot loader should jump in order to
>>> +start running EFI amd64 compatible operating system code.
>>> +@end table
>>> +
>>> +This tag is taken into account only on EFI amd64 platforms
>>> +when Multiboot2 image header contains EFI boot services tag.
>>> +Then entry point specified in ELF header and the entry address
>>> +tag of Multiboot2 header are ignored.
>>> +
>> 
>> Why do we have two different tags for what is effectively the same
> 
> Because x86 32-bit and 64-bit are similar but different things. So, we
> should have both.
> 
>> purpose? Is it possible for the same image to have both of them? Just
>> for my understanding.
> 
> Yes, it is possible, however, I have not seen any real life usage yet.
> 
> Daniel
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@xxxxxxx
> https://lists.gnu.org/mailman/listinfo/grub-devel


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