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

[Daniel Kiper <dkiper@xxxxxxxxxxxx>]

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.

> > +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

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