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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 09/06/2016 21:30, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper <daniel.kiper@xxxxxxxxxx>
> ---
>  doc/multiboot.texi |  108 
> +++++++++++++++++++++++++++++++++++++++++++++++++++-
>  doc/multiboot2.h   |    2 +
>  2 files changed, 108 insertions(+), 2 deletions(-)
>
> diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> index e43df93..1583b76 100644
> --- a/doc/multiboot.texi
> +++ b/doc/multiboot.texi
> @@ -534,6 +534,62 @@ 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 Multiboot 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.
> +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 Multiboot image header contains EFI boot services tag.
> +Then entry point specified in ELF header and the entry address
> +tag of Multiboot header are ignored.
> +
> +@subsection EFI amd64 entry address tag of Multiboot 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.
> +The meaning of each is as follows:

A 64bit entry cannot possibly be a physical, as paging is mandatory.

This is clearly supposed to be the entry virtual address, but it should
not be conflated with the position of the image in RAM.  The chances of
the two being the same is very small.

> +
> +@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 Multiboot image header contains EFI boot services tag.
> +Then entry point specified in ELF header and the entry address
> +tag of Multiboot header are ignored.
> +
>  @node Console header tags
>  @subsection Flags tag
>  
> @@ -714,12 +770,60 @@ The OS image must leave interrupts disabled until it 
> sets up its own
>  
>  On EFI system boot services must be terminated.
>  
> +@section EFI i386 machine state with boot services enabled
> +
> +When the boot loader invokes the 32-bit operating system on EFI i386
> +platform and EFI boot services tag together with EFI i386 entry address
> +tag are present in the image Multiboot header, the machine must have the
> +following state:
> +
> +@table @samp
> +@item EAX
> +Must contain the magic value @samp{0x36d76289}; the presence of this
> +value indicates to the operating system that it was loaded by a
> +Multiboot-compliant boot loader (e.g. as opposed to another type of

Multiboot 2, not multiboot.

> +boot loader that the operating system can also be loaded from).
> +
> +@item EBX
> +Must contain the 32-bit physical address of the Multiboot
> +information structure provided by the boot loader (@pxref{Boot
> +information format}).
> +@end table
> +
> +All other processor registers, flag bits and state are set accordingly
> +to Unified Extensible Firmware Interface Specification, Version 2.6,
> +section 2.3.2, IA-32 Platforms, boot services.
> +
> +@section EFI amd64 machine state with boot services enabled
> +
> +When the boot loader invokes the 64-bit operating system on EFI amd64
> +platform and EFI boot services tag together with EFI amd64 entry address
> +tag are present in the image Multiboot header, the machine must have the
> +following state:
> +
> +@table @samp
> +@item RAX
> +Must contain the magic value @samp{0x36d76289}; the presence of this
> +value indicates to the operating system that it was loaded by a
> +Multiboot-compliant boot loader (e.g. as opposed to another type of

Again, Multiboot 2.

> +boot loader that the operating system can also be loaded from).
> +
> +@item RBX
> +Must contain the 64-bit physical address of the Multiboot

This is surely a virtual address, unless you expect a multiboot payload
to edit its own pagetables before it can read the info structure.

> +information structure provided by the boot loader (@pxref{Boot
> +information format}).
> +@end table
> +
> +All other processor registers, flag bits and state are set accordingly
> +to Unified Extensible Firmware Interface Specification, Version 2.6,
> +section 2.3.4, x64 Platforms, boot services.
> +
>  @node Boot information format
>  @section Boot information
>  @subsection Boot information format
>  
> -Upon entry to the operating system, the @code{EBX} register contains the
> -physical address of a @dfn{Multiboot information} data structure,
> +Upon entry to the operating system, the @code{R5/EBX/RBX} register contains
> +the physical address of a @dfn{Multiboot information} data structure,

Same here.

~Andrew

>  through which the boot loader communicates vital information to the
>  operating system. The operating system can use or ignore any parts of
>  the structure as it chooses; all information passed by the boot loader
> diff --git a/doc/multiboot2.h b/doc/multiboot2.h
> index 78337f5..240400d 100644
> --- a/doc/multiboot2.h
> +++ b/doc/multiboot2.h
> @@ -69,6 +69,8 @@
>  #define MULTIBOOT_HEADER_TAG_FRAMEBUFFER  5
>  #define MULTIBOOT_HEADER_TAG_MODULE_ALIGN  6
>  #define MULTIBOOT_HEADER_TAG_EFI_BS        7
> +#define MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI32  8
> +#define MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI64  9
>  
>  #define MULTIBOOT_ARCHITECTURE_I386  0
>  #define MULTIBOOT_ARCHITECTURE_MIPS32  4


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