[MULTIBOOT2 DOC PATCH v2 00/10] multiboot2: Update documentation

[MULTIBOOT2 DOC PATCH v2 00/10] multiboot2: Update documentation

[Daniel Kiper]

Hi,

This updated patch series adds description of the Multiboot2 protocol new
features and fixes some issues found here and there.

It applies to multiboot2 branch in GRUB2 git tree.

Daniel

 configure.ac       |    2 +-
 doc/multiboot.texi |  366 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------
 doc/multiboot2.h   |   42 ++++++++++++
 3 files changed, 338 insertions(+), 72 deletions(-)

Daniel Kiper (11):
      multiboot2: Rename Multiboot to Multiboot2
      multiboot2: Replace redundant if with the
      multiboot2: Clarify meaning of information request header tag
      multiboot2: Fix description of EFI boot services tag
      multiboot2: Add description of support for EFI boot services
      multiboot2: Add description of EFI image handle tags
      multiboot2: Add description of support for relocatable images
      multiboot2: Say that memory maps may not be available on EFI platforms
      multiboot2: Add C structure members alignment and padding consideration section
      multiboot2: Add me to authors
      multiboot2: Bump version to 2.0

[MULTIBOOT2 DOC PATCH v2 01/11] multiboot2: Rename Multiboot to Multiboot2

[Daniel Kiper]

Multiboot2 is proper name of the boot protocol. Multiboot is name of older boot
protocol. So, rename Multiboot to Multiboot2 to not confuse the reader.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 doc/multiboot.texi |  112 ++++++++++++++++++++++++++--------------------------
 1 file changed, 56 insertions(+), 56 deletions(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 4b92918..d2b940f 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -2,7 +2,7 @@
 @c %**start of header
 @setfilename multiboot.info
 @include version.texi
-@settitle Multiboot Specification version @value{VERSION}
+@settitle Multiboot2 Specification version @value{VERSION}
 @c Unify all our little indices for now.
 @syncodeindex fn cp
 @syncodeindex vr cp
@@ -47,12 +47,12 @@ versions.
 
 @dircategory Kernel
 @direntry
-* Multiboot Specification: (multiboot).		Multiboot Specification.
+* Multiboot2 Specification: (Multiboot2).		Multiboot2 Specification.
 @end direntry
 
 @titlepage
 @sp 10
-@title The Multiboot Specification version @value{VERSION}
+@title The Multiboot2 Specification version @value{VERSION}
 @author Yoshinori K. Okuji, Bryan Ford, Erich Stefan Boleyn, Kunihiro Ishiguro, Vladimir 'phcoder' Serbinenko
 @page
 @vskip 0pt plus 1filll
@@ -64,9 +64,9 @@ versions.
 
 @ifnottex
 @node Top
-@top Multiboot Specification
+@top Multiboot2 Specification
 
-This file documents Multiboot Specification, the proposal for the boot
+This file documents Multiboot2 Specification, the proposal for the boot
 sequence standard. This edition documents version @value{VERSION}.
 
 @insertcopying
@@ -83,9 +83,9 @@ sequence standard. This edition documents version @value{VERSION}.
 
 
 @node Overview
-@chapter Introduction to Multiboot Specification
+@chapter Introduction to Multiboot2 Specification
 
-This chapter describes some rough information on the Multiboot
+This chapter describes some rough information on the Multiboot2
 Specification. Note that this is not a part of the specification itself.
 
 @menu
@@ -100,7 +100,7 @@ Specification. Note that this is not a part of the specification itself.
 
 
 @node Motivation
-@section The background of Multiboot Specification
+@section The background of Multiboot2 Specification
 
 Every operating system ever created tends to have its own boot loader.
 Installing a new operating system on a machine generally involves
@@ -209,13 +209,13 @@ existence in order to load the OS image --- otherwise the boot loader
 effectively becomes operating system specific again.
 
 This specification adopts a compromise solution to this
-problem. Multiboot-compliant OS images always contain a magic
-@dfn{Multiboot header} (@pxref{OS image format}), which allows the boot
+problem. Multiboot2-compliant OS images always contain a magic
+@dfn{Multiboot2 header} (@pxref{OS image format}), which allows the boot
 loader to load the image without having to understand numerous a.out
 variants or other executable formats. This magic header does not need to
 be at the very beginning of the executable file, so kernel images can
 still conform to the local a.out format variant in addition to being
-Multiboot-compliant.
+Multiboot2-compliant.
 
 
 @node Boot modules
@@ -246,7 +246,7 @@ because some operating systems will be unable to boot without them.
 @item must
 We use the term @dfn{must}, when any boot loader or OS image needs to
 follow a rule --- otherwise, the boot loader or OS image is @emph{not}
-Multiboot-compliant.
+Multiboot2-compliant.
 
 @item should
 We use the term @dfn{should}, when any boot loader or OS image is
@@ -263,7 +263,7 @@ consist of several stages, but that is an implementation detail not
 relevant to this specification. Only the @emph{final} stage of the boot
 loader --- the stage that eventually transfers control to an operating
 system --- must follow the rules specified in this document in order
-to be @dfn{Multiboot-compliant}; earlier boot loader stages may be
+to be @dfn{Multiboot2-compliant}; earlier boot loader stages may be
 designed in whatever way is most convenient.
 
 @item OS image, kernel
@@ -278,10 +278,10 @@ Other auxiliary files that a boot loader loads into memory along with
 an OS image, but does not interpret in any way other than passing their
 locations to the operating system when it is invoked.
 
-@item Multiboot-compliant
+@item Multiboot2-compliant
 A boot loader or an OS image which follows the rules defined as
-@dfn{must} is Multiboot-compliant. When this specification specifies a
-rule as @dfn{should} or @dfn{may}, a Multiboot-complaint boot loader/OS
+@dfn{must} is Multiboot2-compliant. When this specification specifies a
+rule as @dfn{should} or @dfn{may}, a Multiboot2-complaint boot loader/OS
 image doesn't need to follow the rule.
 
 @item u8
@@ -309,7 +309,7 @@ The type of unsigned data of the same size as target architecture virtual addres
 
 
 @node Specification
-@chapter The exact definitions of Multiboot Specification
+@chapter The exact definitions of Multiboot2 Specification
 
 There are three main aspects of a boot loader/OS image interface:
 
@@ -342,17 +342,17 @@ linked at a non-default load address to avoid loading on top of the
 @sc{pc}'s I/O region or other reserved areas, and of course it should
 not use shared libraries or other fancy features.
 
-An OS image must contain an additional header called @dfn{Multiboot
+An OS image must contain an additional header called @dfn{Multiboot2
 header}, besides the headers of the format used by the OS image. The
-Multiboot header must be contained completely within the first 32768
+Multiboot2 header must be contained completely within the first 32768
 bytes of the OS image, and must be 64-bit aligned. In
 general, it should come @emph{as early as possible}, and may be
 embedded in the beginning of the text segment after the @emph{real}
 executable header.
 
 @menu
-* Header layout::               The layout of Multiboot header
-* Header magic fields::         The magic fields of Multiboot header
+* Header layout::               The layout of Multiboot2 header
+* Header magic fields::         The magic fields of Multiboot2 header
 * Header tags::
 * Information request header tag::
 * Address header tag::       
@@ -363,9 +363,9 @@ executable header.
 
 
 @node Header layout
-@subsection The layout of Multiboot header
+@subsection The layout of Multiboot2 header
 
-The layout of the Multiboot header must be as follows:
+The layout of the Multiboot2 header must be as follows:
 
 @multitable @columnfractions .1 .1 .2 .5
 @item Offset @tab Type  @tab Field Name   @tab Note
@@ -382,7 +382,7 @@ On bi-endian platforms native-endianness means the endiannes OS image starts in.
 
 
 @node Header magic fields
-@subsection The magic fields of Multiboot header
+@subsection The magic fields of Multiboot2 header
 
 @table @samp
 @item magic
@@ -397,7 +397,7 @@ recieve the same ID. @samp{0} means 32-bit (protected) mode of i386.
 @samp{4} means 32-bit MIPS.
 
 @item header_length
-The field @samp{header_length} specifies the Length of multiboot header
+The field @samp{header_length} specifies the Length of Multiboot2 header
 in bytes including magic fields.
 
 
@@ -430,7 +430,7 @@ lacks relevant support.
 Tags are terminated by a tag of type @samp{0} and size @samp{8}.
 
 @node Information request header tag
-@subsection Multiboot information request
+@subsection Multiboot2 information request
 
 @example
 @group
@@ -455,7 +455,7 @@ actually be present. E.g. on a videoless system even if you requested tag
 
 
 @node Address header tag
-@subsection The address tag of Multiboot header
+@subsection The address tag of Multiboot2 header
 
 @example
 @group
@@ -476,7 +476,7 @@ The meaning of each is as follows:
 
 @table @code
 @item header_addr
-Contains the address corresponding to the beginning of the Multiboot
+Contains the address corresponding to the beginning of the Multiboot2
 header --- the physical memory location at which the magic value is
 supposed to be loaded. This field serves to @dfn{synchronize} the
 mapping between OS image offsets and physical memory addresses.
@@ -506,7 +506,7 @@ assumes that no bss segment is present.
 
 @end table
 
-@subsection The entry address tag of Multiboot header
+@subsection The entry address tag of Multiboot2 header
 
 @example
 @group
@@ -548,7 +548,7 @@ at least one of supported consoles must be present and information about it must
 If bit @samp{1} of @samp{console_flags} is set it
 indicates that the OS image has EGA text support.
 
-@subsection The framebuffer tag of Multiboot header
+@subsection The framebuffer tag of Multiboot2 header
 
 @example
 @group
@@ -630,11 +630,11 @@ must have the following state:
 @item R4 (also known as A0)
 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
+Multiboot2-compliant boot loader (e.g. as opposed to another type of
 boot loader that the operating system can also be loaded from).
 
 @item R5 (also known as A1)
-Must contain the 32-bit physical address of the Multiboot
+Must contain the 32-bit physical address of the Multiboot2
 information structure provided by the boot loader (@pxref{Boot
 information format}).
 @end table
@@ -657,11 +657,11 @@ must have the following state:
 @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
+Multiboot2-compliant boot loader (e.g. as opposed to another type of
 boot loader that the operating system can also be loaded from).
 
 @item EBX
-Must contain the 32-bit physical address of the Multiboot
+Must contain the 32-bit physical address of the Multiboot2
 information structure provided by the boot loader (@pxref{Boot
 information format}).
 
@@ -714,13 +714,13 @@ On EFI system boot services must be terminated.
 @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,
+physical address of a @dfn{Multiboot2 information} data structure,
 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
 is advisory only.
 
-The Multiboot information structure and its related substructures may be
+The Multiboot2 information structure and its related substructures may be
 placed anywhere in memory by the boot loader (with the exception of the
 memory reserved for the kernel and boot modules, of course). It is the
 operating system's responsibility to avoid overwriting this memory until
@@ -1190,14 +1190,14 @@ loader writers.
 @node Notes on PC
 @section Notes on PC
 
-In reference to bit 0 of the @samp{flags} parameter in the Multiboot
+In reference to bit 0 of the @samp{flags} parameter in the Multiboot2
 information structure, if the bootloader in question uses older
 @sc{bios} interfaces, or the newest ones are not available (see
 description about bit 6), then a maximum of either 15 or 63 megabytes of
 memory may be reported. It is @emph{highly} recommended that boot
 loaders perform a thorough memory probe.
 
-In reference to bit 1 of the @samp{flags} parameter in the Multiboot
+In reference to bit 1 of the @samp{flags} parameter in the Multiboot2
 information structure, it is recognized that determination of which
 @sc{bios} drive maps to which device driver in an operating system is
 non-trivial, at best. Many kludges have been made to various operating
@@ -1206,7 +1206,7 @@ many conditions. To encourage the use of general-purpose solutions to
 this problem, there are 2 @sc{bios} device mapping techniques
 (@pxref{BIOS device mapping techniques}). 
 
-In reference to bit 6 of the @samp{flags} parameter in the Multiboot
+In reference to bit 6 of the @samp{flags} parameter in the Multiboot2
 information structure, it is important to note that the data structure
 used there (starting with @samp{BaseAddrLow}) is the data returned by
 the INT 15h, AX=E820h --- Query System Address Map call. See @xref{Query
@@ -1306,18 +1306,18 @@ logically numbered devices on the controller.
 @node Example OS code
 @section Example OS code
 
-In this distribution, the example Multiboot kernel @file{kernel} is
-included. The kernel just prints out the Multiboot information structure
+In this distribution, the example Multiboot2 kernel @file{kernel} is
+included. The kernel just prints out the Multiboot2 information structure
 on the screen, so you can make use of the kernel to test a
-Multiboot-compliant boot loader and for reference to how to implement a
-Multiboot kernel. The source files can be found under the directory
-@file{doc} in the Multiboot source distribution.
+Multiboot2-compliant boot loader and for reference to how to implement a
+Multiboot2 kernel. The source files can be found under the directory
+@file{doc} in the Multiboot2 source distribution.
 
 The kernel @file{kernel} consists of only three files: @file{boot.S},
 @file{kernel.c} and @file{multiboot2.h}. The assembly source
 @file{boot.S} is written in GAS (@pxref{Top, , GNU assembler, as.info,
-The GNU assembler}), and contains the Multiboot information structure to
-comply with the specification. When a Multiboot-compliant boot loader
+The GNU assembler}), and contains the Multiboot2 information structure to
+comply with the specification. When a Multiboot2-compliant boot loader
 loads and execute it, it initialize the stack pointer and @code{EFLAGS},
 and then call the function @code{cmain} defined in @file{kernel.c}. If
 @code{cmain} returns to the callee, then it shows a message to inform
@@ -1326,14 +1326,14 @@ key. The file @file{kernel.c} contains the function @code{cmain},
 which checks if the magic number passed by the boot loader is valid and
 so on, and some functions to print messages on the screen. The file
 @file{multiboot2.h} defines some macros, such as the magic number for the
-Multiboot header, the Multiboot header structure and the Multiboot
+Multiboot2 header, the Multiboot2 header structure and the Multiboot2
 information structure.
 
 @menu
 * multiboot2.h::                 
 * boot.S::                      
 * kernel.c::                    
-* Other Multiboot kernels::     
+* Other Multiboot2 kernels::     
 @end menu
 
 
@@ -1367,10 +1367,10 @@ And, in the file @file{kernel.c}:
 @end example
 
 
-@node Other Multiboot kernels
-@subsection Other Multiboot kernels
+@node Other Multiboot2 kernels
+@subsection Other Multiboot2 kernels
 
-Other useful information should be available in Multiboot kernels, such
+Other useful information should be available in Multiboot2 kernels, such
 as GNU Mach and Fiasco @url{http://os.inf.tu-dresden.de/fiasco/}. And,
 it is worth mentioning the OSKit
 @url{http://www.cs.utah.edu/projects/flux/oskit/}, which provides a
@@ -1381,7 +1381,7 @@ library supporting the specification.
 @section Example boot loader code
 
 The GNU GRUB (@pxref{Top, , GRUB, grub.info, The GRUB manual}) project
-is a Multiboot-compliant boot loader, supporting all required and
+is a Multiboot2-compliant boot loader, supporting all required and
 many optional features present in this specification. A public release has
 not been made, but the test release is available from:
 
@@ -1398,14 +1398,14 @@ more information.
 @item 0.7
 @itemize @bullet
 @item
-@dfn{Multiboot Standard} is renamed to @dfn{Multiboot Specification}.
+@dfn{Multiboot2 Standard} is renamed to @dfn{Multiboot2 Specification}.
 
 @item
-Graphics fields are added to Multiboot header.
+Graphics fields are added to Multiboot2 header.
 
 @item
 BIOS drive information, BIOS configuration table, the name of a boot
-loader, APM information, and graphics information are added to Multiboot
+loader, APM information, and graphics information are added to Multiboot2
 information.
 
 @item
@@ -1419,7 +1419,7 @@ The maintainer changes to the GNU GRUB maintainer team
 @email{bug-grub@@gnu.org}, from Bryan Ford and Erich Stefan Boleyn.
 
 @item
-The byte order of the @samp{boot_device} in Multiboot information is
+The byte order of the @samp{boot_device} in Multiboot2 information is
 reversed. This was a mistake.
 
 @item
-- 
1.7.10.4


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

[MULTIBOOT2 DOC PATCH v2 01/11] multiboot2: Rename Multiboot to Multiboot2

[Daniel Kiper]

Multiboot2 is proper name of the boot protocol. Multiboot is name of older boot
protocol. So, rename Multiboot to Multiboot2 to not confuse the reader.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 doc/multiboot.texi |  112 ++++++++++++++++++++++++++--------------------------
 1 file changed, 56 insertions(+), 56 deletions(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 4b92918..d2b940f 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -2,7 +2,7 @@
 @c %**start of header
 @setfilename multiboot.info
 @include version.texi
-@settitle Multiboot Specification version @value{VERSION}
+@settitle Multiboot2 Specification version @value{VERSION}
 @c Unify all our little indices for now.
 @syncodeindex fn cp
 @syncodeindex vr cp
@@ -47,12 +47,12 @@ versions.
 
 @dircategory Kernel
 @direntry
-* Multiboot Specification: (multiboot).		Multiboot Specification.
+* Multiboot2 Specification: (Multiboot2).		Multiboot2 Specification.
 @end direntry
 
 @titlepage
 @sp 10
-@title The Multiboot Specification version @value{VERSION}
+@title The Multiboot2 Specification version @value{VERSION}
 @author Yoshinori K. Okuji, Bryan Ford, Erich Stefan Boleyn, Kunihiro Ishiguro, Vladimir 'phcoder' Serbinenko
 @page
 @vskip 0pt plus 1filll
@@ -64,9 +64,9 @@ versions.
 
 @ifnottex
 @node Top
-@top Multiboot Specification
+@top Multiboot2 Specification
 
-This file documents Multiboot Specification, the proposal for the boot
+This file documents Multiboot2 Specification, the proposal for the boot
 sequence standard. This edition documents version @value{VERSION}.
 
 @insertcopying
@@ -83,9 +83,9 @@ sequence standard. This edition documents version @value{VERSION}.
 
 
 @node Overview
-@chapter Introduction to Multiboot Specification
+@chapter Introduction to Multiboot2 Specification
 
-This chapter describes some rough information on the Multiboot
+This chapter describes some rough information on the Multiboot2
 Specification. Note that this is not a part of the specification itself.
 
 @menu
@@ -100,7 +100,7 @@ Specification. Note that this is not a part of the specification itself.
 
 
 @node Motivation
-@section The background of Multiboot Specification
+@section The background of Multiboot2 Specification
 
 Every operating system ever created tends to have its own boot loader.
 Installing a new operating system on a machine generally involves
@@ -209,13 +209,13 @@ existence in order to load the OS image --- otherwise the boot loader
 effectively becomes operating system specific again.
 
 This specification adopts a compromise solution to this
-problem. Multiboot-compliant OS images always contain a magic
-@dfn{Multiboot header} (@pxref{OS image format}), which allows the boot
+problem. Multiboot2-compliant OS images always contain a magic
+@dfn{Multiboot2 header} (@pxref{OS image format}), which allows the boot
 loader to load the image without having to understand numerous a.out
 variants or other executable formats. This magic header does not need to
 be at the very beginning of the executable file, so kernel images can
 still conform to the local a.out format variant in addition to being
-Multiboot-compliant.
+Multiboot2-compliant.
 
 
 @node Boot modules
@@ -246,7 +246,7 @@ because some operating systems will be unable to boot without them.
 @item must
 We use the term @dfn{must}, when any boot loader or OS image needs to
 follow a rule --- otherwise, the boot loader or OS image is @emph{not}
-Multiboot-compliant.
+Multiboot2-compliant.
 
 @item should
 We use the term @dfn{should}, when any boot loader or OS image is
@@ -263,7 +263,7 @@ consist of several stages, but that is an implementation detail not
 relevant to this specification. Only the @emph{final} stage of the boot
 loader --- the stage that eventually transfers control to an operating
 system --- must follow the rules specified in this document in order
-to be @dfn{Multiboot-compliant}; earlier boot loader stages may be
+to be @dfn{Multiboot2-compliant}; earlier boot loader stages may be
 designed in whatever way is most convenient.
 
 @item OS image, kernel
@@ -278,10 +278,10 @@ Other auxiliary files that a boot loader loads into memory along with
 an OS image, but does not interpret in any way other than passing their
 locations to the operating system when it is invoked.
 
-@item Multiboot-compliant
+@item Multiboot2-compliant
 A boot loader or an OS image which follows the rules defined as
-@dfn{must} is Multiboot-compliant. When this specification specifies a
-rule as @dfn{should} or @dfn{may}, a Multiboot-complaint boot loader/OS
+@dfn{must} is Multiboot2-compliant. When this specification specifies a
+rule as @dfn{should} or @dfn{may}, a Multiboot2-complaint boot loader/OS
 image doesn't need to follow the rule.
 
 @item u8
@@ -309,7 +309,7 @@ The type of unsigned data of the same size as target architecture virtual addres
 
 
 @node Specification
-@chapter The exact definitions of Multiboot Specification
+@chapter The exact definitions of Multiboot2 Specification
 
 There are three main aspects of a boot loader/OS image interface:
 
@@ -342,17 +342,17 @@ linked at a non-default load address to avoid loading on top of the
 @sc{pc}'s I/O region or other reserved areas, and of course it should
 not use shared libraries or other fancy features.
 
-An OS image must contain an additional header called @dfn{Multiboot
+An OS image must contain an additional header called @dfn{Multiboot2
 header}, besides the headers of the format used by the OS image. The
-Multiboot header must be contained completely within the first 32768
+Multiboot2 header must be contained completely within the first 32768
 bytes of the OS image, and must be 64-bit aligned. In
 general, it should come @emph{as early as possible}, and may be
 embedded in the beginning of the text segment after the @emph{real}
 executable header.
 
 @menu
-* Header layout::               The layout of Multiboot header
-* Header magic fields::         The magic fields of Multiboot header
+* Header layout::               The layout of Multiboot2 header
+* Header magic fields::         The magic fields of Multiboot2 header
 * Header tags::
 * Information request header tag::
 * Address header tag::       
@@ -363,9 +363,9 @@ executable header.
 
 
 @node Header layout
-@subsection The layout of Multiboot header
+@subsection The layout of Multiboot2 header
 
-The layout of the Multiboot header must be as follows:
+The layout of the Multiboot2 header must be as follows:
 
 @multitable @columnfractions .1 .1 .2 .5
 @item Offset @tab Type  @tab Field Name   @tab Note
@@ -382,7 +382,7 @@ On bi-endian platforms native-endianness means the endiannes OS image starts in.
 
 
 @node Header magic fields
-@subsection The magic fields of Multiboot header
+@subsection The magic fields of Multiboot2 header
 
 @table @samp
 @item magic
@@ -397,7 +397,7 @@ recieve the same ID. @samp{0} means 32-bit (protected) mode of i386.
 @samp{4} means 32-bit MIPS.
 
 @item header_length
-The field @samp{header_length} specifies the Length of multiboot header
+The field @samp{header_length} specifies the Length of Multiboot2 header
 in bytes including magic fields.
 
 
@@ -430,7 +430,7 @@ lacks relevant support.
 Tags are terminated by a tag of type @samp{0} and size @samp{8}.
 
 @node Information request header tag
-@subsection Multiboot information request
+@subsection Multiboot2 information request
 
 @example
 @group
@@ -455,7 +455,7 @@ actually be present. E.g. on a videoless system even if you requested tag
 
 
 @node Address header tag
-@subsection The address tag of Multiboot header
+@subsection The address tag of Multiboot2 header
 
 @example
 @group
@@ -476,7 +476,7 @@ The meaning of each is as follows:
 
 @table @code
 @item header_addr
-Contains the address corresponding to the beginning of the Multiboot
+Contains the address corresponding to the beginning of the Multiboot2
 header --- the physical memory location at which the magic value is
 supposed to be loaded. This field serves to @dfn{synchronize} the
 mapping between OS image offsets and physical memory addresses.
@@ -506,7 +506,7 @@ assumes that no bss segment is present.
 
 @end table
 
-@subsection The entry address tag of Multiboot header
+@subsection The entry address tag of Multiboot2 header
 
 @example
 @group
@@ -548,7 +548,7 @@ at least one of supported consoles must be present and information about it must
 If bit @samp{1} of @samp{console_flags} is set it
 indicates that the OS image has EGA text support.
 
-@subsection The framebuffer tag of Multiboot header
+@subsection The framebuffer tag of Multiboot2 header
 
 @example
 @group
@@ -630,11 +630,11 @@ must have the following state:
 @item R4 (also known as A0)
 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
+Multiboot2-compliant boot loader (e.g. as opposed to another type of
 boot loader that the operating system can also be loaded from).
 
 @item R5 (also known as A1)
-Must contain the 32-bit physical address of the Multiboot
+Must contain the 32-bit physical address of the Multiboot2
 information structure provided by the boot loader (@pxref{Boot
 information format}).
 @end table
@@ -657,11 +657,11 @@ must have the following state:
 @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
+Multiboot2-compliant boot loader (e.g. as opposed to another type of
 boot loader that the operating system can also be loaded from).
 
 @item EBX
-Must contain the 32-bit physical address of the Multiboot
+Must contain the 32-bit physical address of the Multiboot2
 information structure provided by the boot loader (@pxref{Boot
 information format}).
 
@@ -714,13 +714,13 @@ On EFI system boot services must be terminated.
 @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,
+physical address of a @dfn{Multiboot2 information} data structure,
 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
 is advisory only.
 
-The Multiboot information structure and its related substructures may be
+The Multiboot2 information structure and its related substructures may be
 placed anywhere in memory by the boot loader (with the exception of the
 memory reserved for the kernel and boot modules, of course). It is the
 operating system's responsibility to avoid overwriting this memory until
@@ -1190,14 +1190,14 @@ loader writers.
 @node Notes on PC
 @section Notes on PC
 
-In reference to bit 0 of the @samp{flags} parameter in the Multiboot
+In reference to bit 0 of the @samp{flags} parameter in the Multiboot2
 information structure, if the bootloader in question uses older
 @sc{bios} interfaces, or the newest ones are not available (see
 description about bit 6), then a maximum of either 15 or 63 megabytes of
 memory may be reported. It is @emph{highly} recommended that boot
 loaders perform a thorough memory probe.
 
-In reference to bit 1 of the @samp{flags} parameter in the Multiboot
+In reference to bit 1 of the @samp{flags} parameter in the Multiboot2
 information structure, it is recognized that determination of which
 @sc{bios} drive maps to which device driver in an operating system is
 non-trivial, at best. Many kludges have been made to various operating
@@ -1206,7 +1206,7 @@ many conditions. To encourage the use of general-purpose solutions to
 this problem, there are 2 @sc{bios} device mapping techniques
 (@pxref{BIOS device mapping techniques}). 
 
-In reference to bit 6 of the @samp{flags} parameter in the Multiboot
+In reference to bit 6 of the @samp{flags} parameter in the Multiboot2
 information structure, it is important to note that the data structure
 used there (starting with @samp{BaseAddrLow}) is the data returned by
 the INT 15h, AX=E820h --- Query System Address Map call. See @xref{Query
@@ -1306,18 +1306,18 @@ logically numbered devices on the controller.
 @node Example OS code
 @section Example OS code
 
-In this distribution, the example Multiboot kernel @file{kernel} is
-included. The kernel just prints out the Multiboot information structure
+In this distribution, the example Multiboot2 kernel @file{kernel} is
+included. The kernel just prints out the Multiboot2 information structure
 on the screen, so you can make use of the kernel to test a
-Multiboot-compliant boot loader and for reference to how to implement a
-Multiboot kernel. The source files can be found under the directory
-@file{doc} in the Multiboot source distribution.
+Multiboot2-compliant boot loader and for reference to how to implement a
+Multiboot2 kernel. The source files can be found under the directory
+@file{doc} in the Multiboot2 source distribution.
 
 The kernel @file{kernel} consists of only three files: @file{boot.S},
 @file{kernel.c} and @file{multiboot2.h}. The assembly source
 @file{boot.S} is written in GAS (@pxref{Top, , GNU assembler, as.info,
-The GNU assembler}), and contains the Multiboot information structure to
-comply with the specification. When a Multiboot-compliant boot loader
+The GNU assembler}), and contains the Multiboot2 information structure to
+comply with the specification. When a Multiboot2-compliant boot loader
 loads and execute it, it initialize the stack pointer and @code{EFLAGS},
 and then call the function @code{cmain} defined in @file{kernel.c}. If
 @code{cmain} returns to the callee, then it shows a message to inform
@@ -1326,14 +1326,14 @@ key. The file @file{kernel.c} contains the function @code{cmain},
 which checks if the magic number passed by the boot loader is valid and
 so on, and some functions to print messages on the screen. The file
 @file{multiboot2.h} defines some macros, such as the magic number for the
-Multiboot header, the Multiboot header structure and the Multiboot
+Multiboot2 header, the Multiboot2 header structure and the Multiboot2
 information structure.
 
 @menu
 * multiboot2.h::                 
 * boot.S::                      
 * kernel.c::                    
-* Other Multiboot kernels::     
+* Other Multiboot2 kernels::     
 @end menu
 
 
@@ -1367,10 +1367,10 @@ And, in the file @file{kernel.c}:
 @end example
 
 
-@node Other Multiboot kernels
-@subsection Other Multiboot kernels
+@node Other Multiboot2 kernels
+@subsection Other Multiboot2 kernels
 
-Other useful information should be available in Multiboot kernels, such
+Other useful information should be available in Multiboot2 kernels, such
 as GNU Mach and Fiasco @url{http://os.inf.tu-dresden.de/fiasco/}. And,
 it is worth mentioning the OSKit
 @url{http://www.cs.utah.edu/projects/flux/oskit/}, which provides a
@@ -1381,7 +1381,7 @@ library supporting the specification.
 @section Example boot loader code
 
 The GNU GRUB (@pxref{Top, , GRUB, grub.info, The GRUB manual}) project
-is a Multiboot-compliant boot loader, supporting all required and
+is a Multiboot2-compliant boot loader, supporting all required and
 many optional features present in this specification. A public release has
 not been made, but the test release is available from:
 
@@ -1398,14 +1398,14 @@ more information.
 @item 0.7
 @itemize @bullet
 @item
-@dfn{Multiboot Standard} is renamed to @dfn{Multiboot Specification}.
+@dfn{Multiboot2 Standard} is renamed to @dfn{Multiboot2 Specification}.
 
 @item
-Graphics fields are added to Multiboot header.
+Graphics fields are added to Multiboot2 header.
 
 @item
 BIOS drive information, BIOS configuration table, the name of a boot
-loader, APM information, and graphics information are added to Multiboot
+loader, APM information, and graphics information are added to Multiboot2
 information.
 
 @item
@@ -1419,7 +1419,7 @@ The maintainer changes to the GNU GRUB maintainer team
 @email{bug-grub@@gnu.org}, from Bryan Ford and Erich Stefan Boleyn.
 
 @item
-The byte order of the @samp{boot_device} in Multiboot information is
+The byte order of the @samp{boot_device} in Multiboot2 information is
 reversed. This was a mistake.
 
 @item
-- 
1.7.10.4

[MULTIBOOT2 DOC PATCH v2 02/11] multiboot2: Replace redundant if with the

[Daniel Kiper]

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
v2 - suggestions/fixes:
   - replace redundant if with the
     (suggested by Andrew Cooper).
---
 doc/multiboot.texi |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index d2b940f..c438b38 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -425,7 +425,7 @@ u32     | size              |
 
 @samp{type} is divided into 2 parts. Lower contains an identifier of contents of the rest of the tag.
 @samp{size} contains the size of tag including header fields.
-If bit @samp{0} of @samp{flags} (also known as @samp{optional}) is set if bootloader may ignore this tag if it 
+If bit @samp{0} of @samp{flags} (also known as @samp{optional}) is set, the bootloader may ignore this tag if it 
 lacks relevant support.
 Tags are terminated by a tag of type @samp{0} and size @samp{8}.
 
-- 
1.7.10.4


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

[MULTIBOOT2 DOC PATCH v2 02/11] multiboot2: Replace redundant if with the

[Daniel Kiper]

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
v2 - suggestions/fixes:
   - replace redundant if with the
     (suggested by Andrew Cooper).
---
 doc/multiboot.texi |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index d2b940f..c438b38 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -425,7 +425,7 @@ u32     | size              |
 
 @samp{type} is divided into 2 parts. Lower contains an identifier of contents of the rest of the tag.
 @samp{size} contains the size of tag including header fields.
-If bit @samp{0} of @samp{flags} (also known as @samp{optional}) is set if bootloader may ignore this tag if it 
+If bit @samp{0} of @samp{flags} (also known as @samp{optional}) is set, the bootloader may ignore this tag if it 
 lacks relevant support.
 Tags are terminated by a tag of type @samp{0} and size @samp{8}.
 
-- 
1.7.10.4

[MULTIBOOT2 DOC PATCH v2 03/11] multiboot2: Clarify meaning of information request header tag

[Daniel Kiper]

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
v2 - suggestions/fixes:
   - rephrase some sentences
     (suggested by Andrew Cooper),
   - add missing the articles
     (suggested by Andrew Cooper).
---
 doc/multiboot.texi |   20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index c438b38..771aeab 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -443,15 +443,19 @@ u32[n]  | mbi_tag_types     |
 @end group
 @end example
 
-@samp{mbi_tag_types} is an array of u32 each one representing an information
-request
-If this tag is present and @samp{optional} is set to @samp{0} information
-conveyed by requested tag types must be present. If bootloader is unable
-to supply this information it must fail with an error
+@samp{mbi_tag_types} is an array of u32's, each one representing an information request.
 
-Note: it doesn't garantee that any tags of type @samp{mbi_tag_types} will
-actually be present. E.g. on a videoless system even if you requested tag
-@samp{8} no tags of type @samp{8} will be present in mbi.
+If this tag is present and @samp{optional} is set to @samp{0}, the bootloader must
+support the requested tag and be able to provide relevant information to the image
+if it is available. If the bootloader does not understand the meaning of the requested
+tag it must fail with an error. However, if it supports a given tag but the information
+conveyed by it is not available the bootloader does not provide the requested tag in
+the Multiboot2 information structure and passes control to the loaded image as usual.
+
+Note: The above means that there is no guarantee that any tags of type @samp{mbi_tag_types}
+will actually be present. E.g. on a videoless system even if you requested tag @samp{8}
+and the bootloader supports it, no tags of type @samp{8} will be present in the Multiboot2
+information structure.
 
 
 @node Address header tag
-- 
1.7.10.4


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

[MULTIBOOT2 DOC PATCH v2 03/11] multiboot2: Clarify meaning of information request header tag

[Daniel Kiper]

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
v2 - suggestions/fixes:
   - rephrase some sentences
     (suggested by Andrew Cooper),
   - add missing the articles
     (suggested by Andrew Cooper).
---
 doc/multiboot.texi |   20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index c438b38..771aeab 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -443,15 +443,19 @@ u32[n]  | mbi_tag_types     |
 @end group
 @end example
 
-@samp{mbi_tag_types} is an array of u32 each one representing an information
-request
-If this tag is present and @samp{optional} is set to @samp{0} information
-conveyed by requested tag types must be present. If bootloader is unable
-to supply this information it must fail with an error
+@samp{mbi_tag_types} is an array of u32's, each one representing an information request.
 
-Note: it doesn't garantee that any tags of type @samp{mbi_tag_types} will
-actually be present. E.g. on a videoless system even if you requested tag
-@samp{8} no tags of type @samp{8} will be present in mbi.
+If this tag is present and @samp{optional} is set to @samp{0}, the bootloader must
+support the requested tag and be able to provide relevant information to the image
+if it is available. If the bootloader does not understand the meaning of the requested
+tag it must fail with an error. However, if it supports a given tag but the information
+conveyed by it is not available the bootloader does not provide the requested tag in
+the Multiboot2 information structure and passes control to the loaded image as usual.
+
+Note: The above means that there is no guarantee that any tags of type @samp{mbi_tag_types}
+will actually be present. E.g. on a videoless system even if you requested tag @samp{8}
+and the bootloader supports it, no tags of type @samp{8} will be present in the Multiboot2
+information structure.
 
 
 @node Address header tag
-- 
1.7.10.4

[MULTIBOOT2 DOC PATCH v2 04/11] multiboot2: Fix description of EFI boot services tag

[Daniel Kiper]

Without this fix multiboot2 doc build fails. Additionally,
add missing full stop at the end of sentence.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 doc/multiboot.texi |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 771aeab..f0f167e 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -358,6 +358,7 @@ executable header.
 * Address header tag::       
 * Console header tags::
 * Module alignment tag::
+* EFI boot services tag::
 
 @end menu
 
@@ -608,8 +609,8 @@ u32     | size = 8          |
 
 If this tag is present modules must be page aligned.
 
-@node EFI boot services
-@subsection EFI boot services
+@node EFI boot services tag
+@subsection EFI boot services tag
 
 @example
 @group
@@ -622,7 +623,7 @@ u32     | size = 8          |
 @end example
 
 This tag indicates that payload supports starting without
-terminating boot services
+terminating boot services.
 
 @node Machine state
 @section MIPS machine state
-- 
1.7.10.4


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

[MULTIBOOT2 DOC PATCH v2 04/11] multiboot2: Fix description of EFI boot services tag

[Daniel Kiper]

Without this fix multiboot2 doc build fails. Additionally,
add missing full stop at the end of sentence.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 doc/multiboot.texi |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 771aeab..f0f167e 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -358,6 +358,7 @@ executable header.
 * Address header tag::       
 * Console header tags::
 * Module alignment tag::
+* EFI boot services tag::
 
 @end menu
 
@@ -608,8 +609,8 @@ u32     | size = 8          |
 
 If this tag is present modules must be page aligned.
 
-@node EFI boot services
-@subsection EFI boot services
+@node EFI boot services tag
+@subsection EFI boot services tag
 
 @example
 @group
@@ -622,7 +623,7 @@ u32     | size = 8          |
 @end example
 
 This tag indicates that payload supports starting without
-terminating boot services
+terminating boot services.
 
 @node Machine state
 @section MIPS machine state
-- 
1.7.10.4

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

[Daniel Kiper]

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
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.
+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;
+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.
+
 @node Console header tags
 @subsection Flags tag
 
@@ -714,12 +774,63 @@ 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 Multiboot2 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
+boot loader that the operating system can also be loaded from).
+
+@item EBX
+Must contain the 32-bit physical address of the Multiboot2
+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 Multiboot2 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
+boot loader that the operating system can also be loaded from).
+
+@item RBX
+Must contain the 64-bit physical address (paging mode is enabled and any
+memory space defined by the UEFI memory map is identity mapped, hence,
+virtual address equals physical address; Unified Extensible Firmware
+Interface Specification, Version 2.6, section 2.3.4, x64 Platforms, boot
+services) of the Multiboot2 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{Multiboot2 information} data structure,
+Upon entry to the operating system, the @code{R5/EBX/RBX} register contains
+the physical address of a @dfn{Multiboot2 information} data structure,
 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
-- 
1.7.10.4


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

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

[Daniel Kiper]

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
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.
+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;
+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.
+
 @node Console header tags
 @subsection Flags tag
 
@@ -714,12 +774,63 @@ 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 Multiboot2 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
+boot loader that the operating system can also be loaded from).
+
+@item EBX
+Must contain the 32-bit physical address of the Multiboot2
+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 Multiboot2 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
+boot loader that the operating system can also be loaded from).
+
+@item RBX
+Must contain the 64-bit physical address (paging mode is enabled and any
+memory space defined by the UEFI memory map is identity mapped, hence,
+virtual address equals physical address; Unified Extensible Firmware
+Interface Specification, Version 2.6, section 2.3.4, x64 Platforms, boot
+services) of the Multiboot2 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{Multiboot2 information} data structure,
+Upon entry to the operating system, the @code{R5/EBX/RBX} register contains
+the physical address of a @dfn{Multiboot2 information} data structure,
 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
-- 
1.7.10.4

[MULTIBOOT2 DOC PATCH v2 06/11] multiboot2: Add description of EFI image handle tags

[Daniel Kiper]

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 doc/multiboot.texi |   28 ++++++++++++++++++++++++++++
 doc/multiboot2.h   |   16 ++++++++++++++++
 2 files changed, 44 insertions(+)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index cc1edab..dca3e62 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -1288,6 +1288,34 @@ u32     | size = 8          |
 
 This tag indicates ExitBootServices wasn't called
 
+@subsection EFI 32-bit image handle pointer
+@example
+@group
+        +-------------------+
+u32     | type = 19         |
+u32     | size = 12         |
+u32     | pointer           |
+        +-------------------+
+@end group
+@end example
+
+This tag contains pointer to EFI i386 image handle.
+Usually it is boot loader image handle.
+
+@subsection EFI 64-bit image handle pointer
+@example
+@group
+        +-------------------+
+u32     | type = 20         |
+u32     | size = 16         |
+u64     | pointer           |
+        +-------------------+
+@end group
+@end example
+
+This tag contains pointer to EFI amd64 image handle.
+Usually it is boot loader image handle.
+
 @node Examples
 @chapter Examples
 
diff --git a/doc/multiboot2.h b/doc/multiboot2.h
index 240400d..b85cb13 100644
--- a/doc/multiboot2.h
+++ b/doc/multiboot2.h
@@ -60,6 +60,8 @@
 #define MULTIBOOT_TAG_TYPE_NETWORK           16
 #define MULTIBOOT_TAG_TYPE_EFI_MMAP          17
 #define MULTIBOOT_TAG_TYPE_EFI_BS            18
+#define MULTIBOOT_TAG_TYPE_EFI32_IH          19
+#define MULTIBOOT_TAG_TYPE_EFI64_IH          20
 
 #define MULTIBOOT_HEADER_TAG_END  0
 #define MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST  1
@@ -372,6 +374,20 @@ struct multiboot_tag_efi_mmap
   multiboot_uint8_t efi_mmap[0];
 }; 
 
+struct multiboot_tag_efi32_ih
+{
+  multiboot_uint32_t type;
+  multiboot_uint32_t size;
+  multiboot_uint32_t pointer;
+};
+
+struct multiboot_tag_efi64_ih
+{
+  multiboot_uint32_t type;
+  multiboot_uint32_t size;
+  multiboot_uint64_t pointer;
+};
+
 #endif /* ! ASM_FILE */
 
 #endif /* ! MULTIBOOT_HEADER */
-- 
1.7.10.4


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

[MULTIBOOT2 DOC PATCH v2 06/11] multiboot2: Add description of EFI image handle tags

[Daniel Kiper]

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 doc/multiboot.texi |   28 ++++++++++++++++++++++++++++
 doc/multiboot2.h   |   16 ++++++++++++++++
 2 files changed, 44 insertions(+)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index cc1edab..dca3e62 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -1288,6 +1288,34 @@ u32     | size = 8          |
 
 This tag indicates ExitBootServices wasn't called
 
+@subsection EFI 32-bit image handle pointer
+@example
+@group
+        +-------------------+
+u32     | type = 19         |
+u32     | size = 12         |
+u32     | pointer           |
+        +-------------------+
+@end group
+@end example
+
+This tag contains pointer to EFI i386 image handle.
+Usually it is boot loader image handle.
+
+@subsection EFI 64-bit image handle pointer
+@example
+@group
+        +-------------------+
+u32     | type = 20         |
+u32     | size = 16         |
+u64     | pointer           |
+        +-------------------+
+@end group
+@end example
+
+This tag contains pointer to EFI amd64 image handle.
+Usually it is boot loader image handle.
+
 @node Examples
 @chapter Examples
 
diff --git a/doc/multiboot2.h b/doc/multiboot2.h
index 240400d..b85cb13 100644
--- a/doc/multiboot2.h
+++ b/doc/multiboot2.h
@@ -60,6 +60,8 @@
 #define MULTIBOOT_TAG_TYPE_NETWORK           16
 #define MULTIBOOT_TAG_TYPE_EFI_MMAP          17
 #define MULTIBOOT_TAG_TYPE_EFI_BS            18
+#define MULTIBOOT_TAG_TYPE_EFI32_IH          19
+#define MULTIBOOT_TAG_TYPE_EFI64_IH          20
 
 #define MULTIBOOT_HEADER_TAG_END  0
 #define MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST  1
@@ -372,6 +374,20 @@ struct multiboot_tag_efi_mmap
   multiboot_uint8_t efi_mmap[0];
 }; 
 
+struct multiboot_tag_efi32_ih
+{
+  multiboot_uint32_t type;
+  multiboot_uint32_t size;
+  multiboot_uint32_t pointer;
+};
+
+struct multiboot_tag_efi64_ih
+{
+  multiboot_uint32_t type;
+  multiboot_uint32_t size;
+  multiboot_uint64_t pointer;
+};
+
 #endif /* ! ASM_FILE */
 
 #endif /* ! MULTIBOOT_HEADER */
-- 
1.7.10.4

[MULTIBOOT2 DOC PATCH v2 07/11] multiboot2: Add description of support for relocatable images

[Daniel Kiper]

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
v2 - suggestions/fixes:
   - add missing the articles
     (suggested by Andrew Cooper),
   - various minor cleanups and fixes
     (suggested by Andrew Cooper).
---
 doc/multiboot.texi |   56 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 doc/multiboot2.h   |   24 ++++++++++++++++++++++
 2 files changed, 80 insertions(+)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index dca3e62..973be9f 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -359,6 +359,7 @@ executable header.
 * Console header tags::
 * Module alignment tag::
 * EFI boot services tag::
+* Relocatable header tag::
 
 @end menu
 
@@ -685,6 +686,47 @@ u32     | size = 8          |
 This tag indicates that payload supports starting without
 terminating boot services.
 
+@node Relocatable header tag
+@subsection Relocatable header tag
+
+@example
+@group
+        +-------------------+
+u16     | type = 10         |
+u16     | flags             |
+u32     | size = 24         |
+u32     | min_addr          |
+u32     | max_addr          |
+u32     | align             |
+u32     | preference        |
+        +-------------------+
+@end group
+@end example
+
+This tag indicates that image is relocatable.
+
+The meaning of each field is as follows:
+
+@table @code
+@item min_addr
+Lowest possible physical address at which image should be loaded.
+The bootloader cannot load any part of image below this address.
+
+@item max_addr
+Highest possible physical address at which loaded image should end.
+The bootloader cannot load any part of image above this address.
+
+@item align
+Image alignment in memory, e.g. 4096.
+
+@item preference
+It contains load address placement suggestion for boot loader.
+Boot loader should follow it. @samp{0} means none, @samp{1} means
+load image at lowest possible address but not lower than min_addr
+and @samp{2} means load image at highest possible address but not
+higher than max_addr.
+@end table
+
 @node Machine state
 @section MIPS machine state
 
@@ -1316,6 +1358,20 @@ u64     | pointer           |
 This tag contains pointer to EFI amd64 image handle.
 Usually it is boot loader image handle.
 
+@subsection Image load base physical address
+@example
+@group
+        +-------------------+
+u32     | type = 21         |
+u32     | size = 12         |
+u32     | load_base_addr    |
+        +-------------------+
+@end group
+@end example
+
+This tag contains image load base physical address. It is
+provided only if image has relocatable header tag.
+
 @node Examples
 @chapter Examples
 
diff --git a/doc/multiboot2.h b/doc/multiboot2.h
index b85cb13..b181607 100644
--- a/doc/multiboot2.h
+++ b/doc/multiboot2.h
@@ -62,6 +62,7 @@
 #define MULTIBOOT_TAG_TYPE_EFI_BS            18
 #define MULTIBOOT_TAG_TYPE_EFI32_IH          19
 #define MULTIBOOT_TAG_TYPE_EFI64_IH          20
+#define MULTIBOOT_TAG_TYPE_LOAD_BASE_ADDR    21
 
 #define MULTIBOOT_HEADER_TAG_END  0
 #define MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST  1
@@ -73,11 +74,16 @@
 #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_HEADER_TAG_RELOCATABLE  10
 
 #define MULTIBOOT_ARCHITECTURE_I386  0
 #define MULTIBOOT_ARCHITECTURE_MIPS32  4
 #define MULTIBOOT_HEADER_TAG_OPTIONAL 1
 
+#define MULTIBOOT_LOAD_PREFERENCE_NONE 0
+#define MULTIBOOT_LOAD_PREFERENCE_LOW 1
+#define MULTIBOOT_LOAD_PREFERENCE_HIGH 2
+
 #define MULTIBOOT_CONSOLE_FLAGS_CONSOLE_REQUIRED 1
 #define MULTIBOOT_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED 2
 
@@ -162,6 +168,17 @@ struct multiboot_header_tag_module_align
   multiboot_uint32_t size;
 };
 
+struct multiboot_header_tag_relocatable
+{
+  multiboot_uint16_t type;
+  multiboot_uint16_t flags;
+  multiboot_uint32_t size;
+  multiboot_uint32_t min_addr;
+  multiboot_uint32_t max_addr;
+  multiboot_uint32_t align;
+  multiboot_uint32_t preference;
+};
+
 struct multiboot_color
 {
   multiboot_uint8_t red;
@@ -388,6 +405,13 @@ struct multiboot_tag_efi64_ih
   multiboot_uint64_t pointer;
 };
 
+struct multiboot_tag_load_base_addr
+{
+  multiboot_uint32_t type;
+  multiboot_uint32_t size;
+  multiboot_uint32_t load_base_addr;
+};
+
 #endif /* ! ASM_FILE */
 
 #endif /* ! MULTIBOOT_HEADER */
-- 
1.7.10.4


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

[MULTIBOOT2 DOC PATCH v2 07/11] multiboot2: Add description of support for relocatable images

[Daniel Kiper]

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
v2 - suggestions/fixes:
   - add missing the articles
     (suggested by Andrew Cooper),
   - various minor cleanups and fixes
     (suggested by Andrew Cooper).
---
 doc/multiboot.texi |   56 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 doc/multiboot2.h   |   24 ++++++++++++++++++++++
 2 files changed, 80 insertions(+)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index dca3e62..973be9f 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -359,6 +359,7 @@ executable header.
 * Console header tags::
 * Module alignment tag::
 * EFI boot services tag::
+* Relocatable header tag::
 
 @end menu
 
@@ -685,6 +686,47 @@ u32     | size = 8          |
 This tag indicates that payload supports starting without
 terminating boot services.
 
+@node Relocatable header tag
+@subsection Relocatable header tag
+
+@example
+@group
+        +-------------------+
+u16     | type = 10         |
+u16     | flags             |
+u32     | size = 24         |
+u32     | min_addr          |
+u32     | max_addr          |
+u32     | align             |
+u32     | preference        |
+        +-------------------+
+@end group
+@end example
+
+This tag indicates that image is relocatable.
+
+The meaning of each field is as follows:
+
+@table @code
+@item min_addr
+Lowest possible physical address at which image should be loaded.
+The bootloader cannot load any part of image below this address.
+
+@item max_addr
+Highest possible physical address at which loaded image should end.
+The bootloader cannot load any part of image above this address.
+
+@item align
+Image alignment in memory, e.g. 4096.
+
+@item preference
+It contains load address placement suggestion for boot loader.
+Boot loader should follow it. @samp{0} means none, @samp{1} means
+load image at lowest possible address but not lower than min_addr
+and @samp{2} means load image at highest possible address but not
+higher than max_addr.
+@end table
+
 @node Machine state
 @section MIPS machine state
 
@@ -1316,6 +1358,20 @@ u64     | pointer           |
 This tag contains pointer to EFI amd64 image handle.
 Usually it is boot loader image handle.
 
+@subsection Image load base physical address
+@example
+@group
+        +-------------------+
+u32     | type = 21         |
+u32     | size = 12         |
+u32     | load_base_addr    |
+        +-------------------+
+@end group
+@end example
+
+This tag contains image load base physical address. It is
+provided only if image has relocatable header tag.
+
 @node Examples
 @chapter Examples
 
diff --git a/doc/multiboot2.h b/doc/multiboot2.h
index b85cb13..b181607 100644
--- a/doc/multiboot2.h
+++ b/doc/multiboot2.h
@@ -62,6 +62,7 @@
 #define MULTIBOOT_TAG_TYPE_EFI_BS            18
 #define MULTIBOOT_TAG_TYPE_EFI32_IH          19
 #define MULTIBOOT_TAG_TYPE_EFI64_IH          20
+#define MULTIBOOT_TAG_TYPE_LOAD_BASE_ADDR    21
 
 #define MULTIBOOT_HEADER_TAG_END  0
 #define MULTIBOOT_HEADER_TAG_INFORMATION_REQUEST  1
@@ -73,11 +74,16 @@
 #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_HEADER_TAG_RELOCATABLE  10
 
 #define MULTIBOOT_ARCHITECTURE_I386  0
 #define MULTIBOOT_ARCHITECTURE_MIPS32  4
 #define MULTIBOOT_HEADER_TAG_OPTIONAL 1
 
+#define MULTIBOOT_LOAD_PREFERENCE_NONE 0
+#define MULTIBOOT_LOAD_PREFERENCE_LOW 1
+#define MULTIBOOT_LOAD_PREFERENCE_HIGH 2
+
 #define MULTIBOOT_CONSOLE_FLAGS_CONSOLE_REQUIRED 1
 #define MULTIBOOT_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED 2
 
@@ -162,6 +168,17 @@ struct multiboot_header_tag_module_align
   multiboot_uint32_t size;
 };
 
+struct multiboot_header_tag_relocatable
+{
+  multiboot_uint16_t type;
+  multiboot_uint16_t flags;
+  multiboot_uint32_t size;
+  multiboot_uint32_t min_addr;
+  multiboot_uint32_t max_addr;
+  multiboot_uint32_t align;
+  multiboot_uint32_t preference;
+};
+
 struct multiboot_color
 {
   multiboot_uint8_t red;
@@ -388,6 +405,13 @@ struct multiboot_tag_efi64_ih
   multiboot_uint64_t pointer;
 };
 
+struct multiboot_tag_load_base_addr
+{
+  multiboot_uint32_t type;
+  multiboot_uint32_t size;
+  multiboot_uint32_t load_base_addr;
+};
+
 #endif /* ! ASM_FILE */
 
 #endif /* ! MULTIBOOT_HEADER */
-- 
1.7.10.4

[MULTIBOOT2 DOC PATCH v2 08/11] multiboot2: Say that memory maps may not be available on EFI platforms

[Daniel Kiper]

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
v2 - suggestions/fixes:
   - add missing the articles
     (suggested by Andrew Cooper).
---
 doc/multiboot.texi |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 973be9f..9461890 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -934,6 +934,10 @@ possible value for lower memory is 640 kilobytes. The value returned for
 upper memory is maximally the address of the first upper memory hole
 minus 1 megabyte. It is not guaranteed to be this value.
 
+This tag may not be provided by some boot loaders on EFI platforms if EFI boot
+services are enabled and available for the loaded image (EFI boot services
+not terminated tag exists in Multiboot2 information structure).
+
 @subsection BIOS Boot device
 @example
 @group
@@ -1085,6 +1089,10 @@ indicated a reserved area.
 The map provided is guaranteed to list all standard @sc{ram} that should
 be available for normal use. This type however includes the regions occupied by kernel, mbi, segments and modules. Kernel must take care not to overwrite these regions.
 
+This tag may not be provided by some boot loaders on EFI platforms if EFI boot
+services are enabled and available for the loaded image (EFI boot services
+not terminated tag exists in Multiboot2 information structure).
+
 @subsection Boot loader name
 @example
 @group
@@ -1317,6 +1325,9 @@ u32     | descriptor version|
 
 This tag contains EFI memory map as per EFI specification.
 
+This tag may not be provided by some boot loaders on EFI platforms if EFI boot
+services are enabled and available for the loaded image (EFI boot services
+not terminated tag exists in Multiboot2 information structure).
 
 @subsection EFI boot services not terminated
 @example
-- 
1.7.10.4


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

[MULTIBOOT2 DOC PATCH v2 08/11] multiboot2: Say that memory maps may not be available on EFI platforms

[Daniel Kiper]

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
v2 - suggestions/fixes:
   - add missing the articles
     (suggested by Andrew Cooper).
---
 doc/multiboot.texi |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 973be9f..9461890 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -934,6 +934,10 @@ possible value for lower memory is 640 kilobytes. The value returned for
 upper memory is maximally the address of the first upper memory hole
 minus 1 megabyte. It is not guaranteed to be this value.
 
+This tag may not be provided by some boot loaders on EFI platforms if EFI boot
+services are enabled and available for the loaded image (EFI boot services
+not terminated tag exists in Multiboot2 information structure).
+
 @subsection BIOS Boot device
 @example
 @group
@@ -1085,6 +1089,10 @@ indicated a reserved area.
 The map provided is guaranteed to list all standard @sc{ram} that should
 be available for normal use. This type however includes the regions occupied by kernel, mbi, segments and modules. Kernel must take care not to overwrite these regions.
 
+This tag may not be provided by some boot loaders on EFI platforms if EFI boot
+services are enabled and available for the loaded image (EFI boot services
+not terminated tag exists in Multiboot2 information structure).
+
 @subsection Boot loader name
 @example
 @group
@@ -1317,6 +1325,9 @@ u32     | descriptor version|
 
 This tag contains EFI memory map as per EFI specification.
 
+This tag may not be provided by some boot loaders on EFI platforms if EFI boot
+services are enabled and available for the loaded image (EFI boot services
+not terminated tag exists in Multiboot2 information structure).
 
 @subsection EFI boot services not terminated
 @example
-- 
1.7.10.4

[MULTIBOOT2 DOC PATCH v2 09/11] multiboot2: Add C structure members alignment and padding consideration section

[Daniel Kiper]

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
v2 - suggestions/fixes:
   - rephrase whole section
     (suggested by Andrew Cooper).
---
 doc/multiboot.texi |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 9461890..fe134bc 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -1391,6 +1391,7 @@ document, but are included for prospective operating system and boot
 loader writers.
 
 @menu
+* C structure members alignment and padding consideration::
 * Notes on PC::                 
 * BIOS device mapping techniques::  
 * Example OS code::             
@@ -1398,6 +1399,16 @@ loader writers.
 @end menu
 
 
+@node C structure members alignment and padding consideration
+@section C structure members alignment and padding consideration
+
+It is preferred that the structures used for communication between the bootloader
+and the OS image conform to chosen ABI for a given architecture. If it is not
+possible then GCC @samp{__attribute__ ((__packed__))} (or anything else which has
+similar meaning for chosen C compiler) have to be added to relevant structures
+definitions to avoid spurious, in this case, padding and alignment.
+
+
 @node Notes on PC
 @section Notes on PC
 
-- 
1.7.10.4


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

[MULTIBOOT2 DOC PATCH v2 09/11] multiboot2: Add C structure members alignment and padding consideration section

[Daniel Kiper]

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
v2 - suggestions/fixes:
   - rephrase whole section
     (suggested by Andrew Cooper).
---
 doc/multiboot.texi |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 9461890..fe134bc 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -1391,6 +1391,7 @@ document, but are included for prospective operating system and boot
 loader writers.
 
 @menu
+* C structure members alignment and padding consideration::
 * Notes on PC::                 
 * BIOS device mapping techniques::  
 * Example OS code::             
@@ -1398,6 +1399,16 @@ loader writers.
 @end menu
 
 
+@node C structure members alignment and padding consideration
+@section C structure members alignment and padding consideration
+
+It is preferred that the structures used for communication between the bootloader
+and the OS image conform to chosen ABI for a given architecture. If it is not
+possible then GCC @samp{__attribute__ ((__packed__))} (or anything else which has
+similar meaning for chosen C compiler) have to be added to relevant structures
+definitions to avoid spurious, in this case, padding and alignment.
+
+
 @node Notes on PC
 @section Notes on PC
 
-- 
1.7.10.4

[MULTIBOOT2 DOC PATCH v2 10/11] multiboot2: Add me to authors

[Daniel Kiper]

.. and properly format author list.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 doc/multiboot.texi |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index fe134bc..5a3cd5d 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -53,7 +53,9 @@ versions.
 @titlepage
 @sp 10
 @title The Multiboot2 Specification version @value{VERSION}
-@author Yoshinori K. Okuji, Bryan Ford, Erich Stefan Boleyn, Kunihiro Ishiguro, Vladimir 'phcoder' Serbinenko
+@author Yoshinori K. Okuji, Bryan Ford, Erich Stefan Boleyn,
+@author Kunihiro Ishiguro, Vladimir 'phcoder' Serbinenko,
+@author Daniel Kiper
 @page
 @vskip 0pt plus 1filll
 @insertcopying
-- 
1.7.10.4


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

[MULTIBOOT2 DOC PATCH v2 10/11] multiboot2: Add me to authors

[Daniel Kiper]

.. and properly format author list.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 doc/multiboot.texi |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index fe134bc..5a3cd5d 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -53,7 +53,9 @@ versions.
 @titlepage
 @sp 10
 @title The Multiboot2 Specification version @value{VERSION}
-@author Yoshinori K. Okuji, Bryan Ford, Erich Stefan Boleyn, Kunihiro Ishiguro, Vladimir 'phcoder' Serbinenko
+@author Yoshinori K. Okuji, Bryan Ford, Erich Stefan Boleyn,
+@author Kunihiro Ishiguro, Vladimir 'phcoder' Serbinenko,
+@author Daniel Kiper
 @page
 @vskip 0pt plus 1filll
 @insertcopying
-- 
1.7.10.4

[MULTIBOOT2 DOC PATCH v2 11/11] multiboot2: Bump version to 2.0

[Daniel Kiper]

.. and add 2016 to copyright.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 configure.ac       |    2 +-
 doc/multiboot.texi |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index b11961d..585b37a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -13,7 +13,7 @@ dnl LIABILITY OF ANY KIND FOR ANY DAMAGES WHATSOEVER RESULTING FROM THE
 dnl USE OF THIS SOFTWARE.
 
 AC_PREREQ(2.59)
-AC_INIT([Multiboot], [1.6], [bug-grub@gnu.org])
+AC_INIT([Multiboot], [2.0], [bug-grub@gnu.org])
 AC_CONFIG_SRCDIR([doc/multiboot.texi])
 AC_CONFIG_HEADER([config.h])
 AM_INIT_AUTOMAKE
diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 5a3cd5d..b76dfe3 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -20,7 +20,7 @@ Copyright @copyright{} 1995,96 Bryan Ford <baford@@cs.utah.edu>
 
 Copyright @copyright{} 1995,96 Erich Stefan Boleyn <erich@@uruk.org>
 
-Copyright @copyright{} 1999,2000,2001,2002,2005,2006,2009,2010 Free Software Foundation, Inc.
+Copyright @copyright{} 1999,2000,2001,2002,2005,2006,2009,2010,2016 Free Software Foundation, Inc.
 
 @quotation
 Permission is granted to make and distribute verbatim copies of
-- 
1.7.10.4


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

[MULTIBOOT2 DOC PATCH v2 11/11] multiboot2: Bump version to 2.0

[Daniel Kiper]

.. and add 2016 to copyright.

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
 configure.ac       |    2 +-
 doc/multiboot.texi |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index b11961d..585b37a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -13,7 +13,7 @@ dnl LIABILITY OF ANY KIND FOR ANY DAMAGES WHATSOEVER RESULTING FROM THE
 dnl USE OF THIS SOFTWARE.
 
 AC_PREREQ(2.59)
-AC_INIT([Multiboot], [1.6], [bug-grub@gnu.org])
+AC_INIT([Multiboot], [2.0], [bug-grub@gnu.org])
 AC_CONFIG_SRCDIR([doc/multiboot.texi])
 AC_CONFIG_HEADER([config.h])
 AM_INIT_AUTOMAKE
diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 5a3cd5d..b76dfe3 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -20,7 +20,7 @@ Copyright @copyright{} 1995,96 Bryan Ford <baford@@cs.utah.edu>
 
 Copyright @copyright{} 1995,96 Erich Stefan Boleyn <erich@@uruk.org>
 
-Copyright @copyright{} 1999,2000,2001,2002,2005,2006,2009,2010 Free Software Foundation, Inc.
+Copyright @copyright{} 1999,2000,2001,2002,2005,2006,2009,2010,2016 Free Software Foundation, Inc.
 
 @quotation
 Permission is granted to make and distribute verbatim copies of
-- 
1.7.10.4

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

[Toomas Soome]

There is still the same confusion as with entry address tag 7; the diagram has 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.

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…

rgds,
toomas


> On 24. nov 2016, at 22:40, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> 
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
> 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.
> +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;
> +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.
> +
> @node Console header tags
> @subsection Flags tag
> 
> @@ -714,12 +774,63 @@ 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 Multiboot2 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
> +boot loader that the operating system can also be loaded from).
> +
> +@item EBX
> +Must contain the 32-bit physical address of the Multiboot2
> +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 Multiboot2 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
> +boot loader that the operating system can also be loaded from).
> +
> +@item RBX
> +Must contain the 64-bit physical address (paging mode is enabled and any
> +memory space defined by the UEFI memory map is identity mapped, hence,
> +virtual address equals physical address; Unified Extensible Firmware
> +Interface Specification, Version 2.6, section 2.3.4, x64 Platforms, boot
> +services) of the Multiboot2 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{Multiboot2 information} data structure,
> +Upon entry to the operating system, the @code{R5/EBX/RBX} register contains
> +the physical address of a @dfn{Multiboot2 information} data structure,
> 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
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


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

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

[Toomas Soome]

There is still the same confusion as with entry address tag 7; the diagram has 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.

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…

rgds,
toomas


> On 24. nov 2016, at 22:40, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> 
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
> 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.
> +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;
> +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.
> +
> @node Console header tags
> @subsection Flags tag
> 
> @@ -714,12 +774,63 @@ 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 Multiboot2 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
> +boot loader that the operating system can also be loaded from).
> +
> +@item EBX
> +Must contain the 32-bit physical address of the Multiboot2
> +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 Multiboot2 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
> +boot loader that the operating system can also be loaded from).
> +
> +@item RBX
> +Must contain the 64-bit physical address (paging mode is enabled and any
> +memory space defined by the UEFI memory map is identity mapped, hence,
> +virtual address equals physical address; Unified Extensible Firmware
> +Interface Specification, Version 2.6, section 2.3.4, x64 Platforms, boot
> +services) of the Multiboot2 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{Multiboot2 information} data structure,
> +Upon entry to the operating system, the @code{R5/EBX/RBX} register contains
> +the physical address of a @dfn{Multiboot2 information} data structure,
> 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
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

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

[Daniel Kiper]

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

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

[Daniel Kiper]

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

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

[Toomas Soome]

> On 28. nov 2016, at 17:46, Daniel Kiper <dkiper@net-space.pl> wrote:
> 
> 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.
> 

Yes, sorry:)

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


Well, yes, I know about 4GB practical limit, and thats why I think it’s ok to use 32bit address there - just I wanted to point out that it may be good idea to have it explicitly noted.

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

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

[Toomas Soome]

> On 28. nov 2016, at 17:46, Daniel Kiper <dkiper@net-space.pl> wrote:
> 
> 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.
> 

Yes, sorry:)

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


Well, yes, I know about 4GB practical limit, and thats why I think it’s ok to use 32bit address there - just I wanted to point out that it may be good idea to have it explicitly noted.

rgds,
toomas

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

[Andrei Borzenkov]

24.11.2016 23:40, Daniel Kiper пишет:
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
> 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
between u_phys and u_virt? Also for type == 3?

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

> +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
purpose? Is it possible for the same image to have both of them? Just
for my understanding.


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

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

[Andrei Borzenkov]

24.11.2016 23:40, Daniel Kiper пишет:
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
> 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
between u_phys and u_virt? Also for type == 3?

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

> +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
purpose? Is it possible for the same image to have both of them? Just
for my understanding.

Re: [MULTIBOOT2 DOC PATCH v2 06/11] multiboot2: Add description of EFI image handle tags

[Andrei Borzenkov]

24.11.2016 23:40, Daniel Kiper пишет:
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  doc/multiboot.texi |   28 ++++++++++++++++++++++++++++
>  doc/multiboot2.h   |   16 ++++++++++++++++
>  2 files changed, 44 insertions(+)
> 
> diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> index cc1edab..dca3e62 100644
> --- a/doc/multiboot.texi
> +++ b/doc/multiboot.texi
> @@ -1288,6 +1288,34 @@ u32     | size = 8          |
>  
>  This tag indicates ExitBootServices wasn't called
>  
> +@subsection EFI 32-bit image handle pointer
> +@example
> +@group
> +        +-------------------+
> +u32     | type = 19         |
> +u32     | size = 12         |
> +u32     | pointer           |

Why it is not u_phys or u_virt as appropriate?

> +        +-------------------+
> +@end group
> +@end example
> +
> +This tag contains pointer to EFI i386 image handle.
> +Usually it is boot loader image handle.
> +
> +@subsection EFI 64-bit image handle pointer
> +@example
> +@group
> +        +-------------------+
> +u32     | type = 20         |
> +u32     | size = 16         |
> +u64     | pointer           |

Same. Again, why there are two tags in the first place? It sounds like
perfect fit for "data of the same size as target architecture
[virtual|physical] address size".



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

Re: [MULTIBOOT2 DOC PATCH v2 06/11] multiboot2: Add description of EFI image handle tags

[Andrei Borzenkov]

24.11.2016 23:40, Daniel Kiper пишет:
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  doc/multiboot.texi |   28 ++++++++++++++++++++++++++++
>  doc/multiboot2.h   |   16 ++++++++++++++++
>  2 files changed, 44 insertions(+)
> 
> diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> index cc1edab..dca3e62 100644
> --- a/doc/multiboot.texi
> +++ b/doc/multiboot.texi
> @@ -1288,6 +1288,34 @@ u32     | size = 8          |
>  
>  This tag indicates ExitBootServices wasn't called
>  
> +@subsection EFI 32-bit image handle pointer
> +@example
> +@group
> +        +-------------------+
> +u32     | type = 19         |
> +u32     | size = 12         |
> +u32     | pointer           |

Why it is not u_phys or u_virt as appropriate?

> +        +-------------------+
> +@end group
> +@end example
> +
> +This tag contains pointer to EFI i386 image handle.
> +Usually it is boot loader image handle.
> +
> +@subsection EFI 64-bit image handle pointer
> +@example
> +@group
> +        +-------------------+
> +u32     | type = 20         |
> +u32     | size = 16         |
> +u64     | pointer           |

Same. Again, why there are two tags in the first place? It sounds like
perfect fit for "data of the same size as target architecture
[virtual|physical] address size".

Re: [MULTIBOOT2 DOC PATCH v2 01/11] multiboot2: Rename Multiboot to Multiboot2

[Andrei Borzenkov]

24.11.2016 23:40, Daniel Kiper пишет:
> Multiboot2 is proper name of the boot protocol. Multiboot is name of older boot
> protocol. So, rename Multiboot to Multiboot2 to not confuse the reader.
> 
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  doc/multiboot.texi |  112 ++++++++++++++++++++++++++--------------------------

What about file name itself? It makes it impossible for multiboot and
multiboot2 documentation to coexist (or forces every downstream to
rename it anyway).


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

Re: [MULTIBOOT2 DOC PATCH v2 01/11] multiboot2: Rename Multiboot to Multiboot2

[Andrei Borzenkov]

24.11.2016 23:40, Daniel Kiper пишет:
> Multiboot2 is proper name of the boot protocol. Multiboot is name of older boot
> protocol. So, rename Multiboot to Multiboot2 to not confuse the reader.
> 
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  doc/multiboot.texi |  112 ++++++++++++++++++++++++++--------------------------

What about file name itself? It makes it impossible for multiboot and
multiboot2 documentation to coexist (or forces every downstream to
rename it anyway).

Re: [MULTIBOOT2 DOC PATCH v2 01/11] multiboot2: Rename Multiboot to Multiboot2

[Daniel Kiper]

On Mon, Nov 28, 2016 at 09:06:32PM +0300, Andrei Borzenkov wrote:
> 24.11.2016 23:40, Daniel Kiper ?????:
> > Multiboot2 is proper name of the boot protocol. Multiboot is name of older boot
> > protocol. So, rename Multiboot to Multiboot2 to not confuse the reader.
> >
> > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> > ---
> >  doc/multiboot.texi |  112 ++++++++++++++++++++++++++--------------------------
>
> What about file name itself? It makes it impossible for multiboot and
> multiboot2 documentation to coexist (or forces every downstream to
> rename it anyway).

I thought about that but decided to not do that as a part of this series.
I would like to remove worst warts and add description of new features
available in GRUB here. No more no less. However, longterm goal (after
2.02 release) is wider spec cleanup and merge with master (currently
Multiboot and Multiboot2 spec exists in separate branches which makes
visibility/availability/maintenance/etc. more difficult). Then I am going
to rename most of the files to multiboot2 and do other needed things.

Daniel

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

Re: [MULTIBOOT2 DOC PATCH v2 01/11] multiboot2: Rename Multiboot to Multiboot2

[Daniel Kiper]

On Mon, Nov 28, 2016 at 09:06:32PM +0300, Andrei Borzenkov wrote:
> 24.11.2016 23:40, Daniel Kiper ?????:
> > Multiboot2 is proper name of the boot protocol. Multiboot is name of older boot
> > protocol. So, rename Multiboot to Multiboot2 to not confuse the reader.
> >
> > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> > ---
> >  doc/multiboot.texi |  112 ++++++++++++++++++++++++++--------------------------
>
> What about file name itself? It makes it impossible for multiboot and
> multiboot2 documentation to coexist (or forces every downstream to
> rename it anyway).

I thought about that but decided to not do that as a part of this series.
I would like to remove worst warts and add description of new features
available in GRUB here. No more no less. However, longterm goal (after
2.02 release) is wider spec cleanup and merge with master (currently
Multiboot and Multiboot2 spec exists in separate branches which makes
visibility/availability/maintenance/etc. more difficult). Then I am going
to rename most of the files to multiboot2 and do other needed things.

Daniel

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

[Daniel Kiper]

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@oracle.com>
> > ---
> > 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@lists.xen.org
https://lists.xen.org/xen-devel

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

[Daniel Kiper]

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@oracle.com>
> > ---
> > 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

Re: [MULTIBOOT2 DOC PATCH v2 06/11] multiboot2: Add description of EFI image handle tags

[Daniel Kiper]

On Mon, Nov 28, 2016 at 08:59:38PM +0300, Andrei Borzenkov wrote:
> 24.11.2016 23:40, Daniel Kiper ?????:
> > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> > ---
> >  doc/multiboot.texi |   28 ++++++++++++++++++++++++++++
> >  doc/multiboot2.h   |   16 ++++++++++++++++
> >  2 files changed, 44 insertions(+)
> >
> > diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> > index cc1edab..dca3e62 100644
> > --- a/doc/multiboot.texi
> > +++ b/doc/multiboot.texi
> > @@ -1288,6 +1288,34 @@ u32     | size = 8          |
> >
> >  This tag indicates ExitBootServices wasn't called
> >
> > +@subsection EFI 32-bit image handle pointer
> > +@example
> > +@group
> > +        +-------------------+
> > +u32     | type = 19         |
> > +u32     | size = 12         |
> > +u32     | pointer           |
>
> Why it is not u_phys or u_virt as appropriate?

Because I mimic EFI 32-bit/64-bit system table pointer definitions.

> > +        +-------------------+
> > +@end group
> > +@end example
> > +
> > +This tag contains pointer to EFI i386 image handle.
> > +Usually it is boot loader image handle.
> > +
> > +@subsection EFI 64-bit image handle pointer
> > +@example
> > +@group
> > +        +-------------------+
> > +u32     | type = 20         |
> > +u32     | size = 16         |
> > +u64     | pointer           |
>
> Same. Again, why there are two tags in the first place? It sounds like

Ditto.

> perfect fit for "data of the same size as target architecture
> [virtual|physical] address size".

Well, I agree that we should remove u_phys/u_virt mess. However, I prefer
to do that later (after 2.02 release) as a part of larger cleanup.

Daniel

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

Re: [MULTIBOOT2 DOC PATCH v2 06/11] multiboot2: Add description of EFI image handle tags

[Daniel Kiper]

On Mon, Nov 28, 2016 at 08:59:38PM +0300, Andrei Borzenkov wrote:
> 24.11.2016 23:40, Daniel Kiper ?????:
> > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> > ---
> >  doc/multiboot.texi |   28 ++++++++++++++++++++++++++++
> >  doc/multiboot2.h   |   16 ++++++++++++++++
> >  2 files changed, 44 insertions(+)
> >
> > diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> > index cc1edab..dca3e62 100644
> > --- a/doc/multiboot.texi
> > +++ b/doc/multiboot.texi
> > @@ -1288,6 +1288,34 @@ u32     | size = 8          |
> >
> >  This tag indicates ExitBootServices wasn't called
> >
> > +@subsection EFI 32-bit image handle pointer
> > +@example
> > +@group
> > +        +-------------------+
> > +u32     | type = 19         |
> > +u32     | size = 12         |
> > +u32     | pointer           |
>
> Why it is not u_phys or u_virt as appropriate?

Because I mimic EFI 32-bit/64-bit system table pointer definitions.

> > +        +-------------------+
> > +@end group
> > +@end example
> > +
> > +This tag contains pointer to EFI i386 image handle.
> > +Usually it is boot loader image handle.
> > +
> > +@subsection EFI 64-bit image handle pointer
> > +@example
> > +@group
> > +        +-------------------+
> > +u32     | type = 20         |
> > +u32     | size = 16         |
> > +u64     | pointer           |
>
> Same. Again, why there are two tags in the first place? It sounds like

Ditto.

> perfect fit for "data of the same size as target architecture
> [virtual|physical] address size".

Well, I agree that we should remove u_phys/u_virt mess. However, I prefer
to do that later (after 2.02 release) as a part of larger cleanup.

Daniel

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

[Toomas Soome]

> On 29. nov 2016, at 11:08, Daniel Kiper <dkiper@net-space.pl> 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@oracle.com>
>>> ---
>>> 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@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


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

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

[Toomas Soome]

> On 29. nov 2016, at 11:08, Daniel Kiper <dkiper@net-space.pl> 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@oracle.com>
>>> ---
>>> 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@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

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

[Daniel Kiper]

On Tue, Nov 29, 2016 at 11:39:39AM +0200, Toomas Soome wrote:
> > On 29. nov 2016, at 11:08, Daniel Kiper <dkiper@net-space.pl> 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@oracle.com>
> >>> ---
> >>> 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??? ;)

Ugh... Then I think that we can safely replace u_phys/u_virt with u32. I have
checked spec and it looks that it requires less changes than I expected. So,
I can add separate patch(es) fixing that. Though I should take a look at MIPS
part in spec too to not break its stuff. Does it make sense?

Daniel

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

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

[Daniel Kiper]

On Tue, Nov 29, 2016 at 11:39:39AM +0200, Toomas Soome wrote:
> > On 29. nov 2016, at 11:08, Daniel Kiper <dkiper@net-space.pl> 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@oracle.com>
> >>> ---
> >>> 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??? ;)

Ugh... Then I think that we can safely replace u_phys/u_virt with u32. I have
checked spec and it looks that it requires less changes than I expected. So,
I can add separate patch(es) fixing that. Though I should take a look at MIPS
part in spec too to not break its stuff. Does it make sense?

Daniel

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

[Toomas Soome]

> On 29. nov 2016, at 12:09, Daniel Kiper <dkiper@net-space.pl> wrote:
> 
> On Tue, Nov 29, 2016 at 11:39:39AM +0200, Toomas Soome wrote:
>>> On 29. nov 2016, at 11:08, Daniel Kiper <dkiper@net-space.pl> 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@oracle.com>
>>>>> ---
>>>>> 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??? ;)
> 
> Ugh... Then I think that we can safely replace u_phys/u_virt with u32. I have
> checked spec and it looks that it requires less changes than I expected. So,
> I can add separate patch(es) fixing that. Though I should take a look at MIPS
> part in spec too to not break its stuff. Does it make sense?
> 
> 

I *think* it does, however, I can not tell about mips - I just do not know about the requirements mips does set:)

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

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

[Toomas Soome]

> On 29. nov 2016, at 12:09, Daniel Kiper <dkiper@net-space.pl> wrote:
> 
> On Tue, Nov 29, 2016 at 11:39:39AM +0200, Toomas Soome wrote:
>>> On 29. nov 2016, at 11:08, Daniel Kiper <dkiper@net-space.pl> 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@oracle.com>
>>>>> ---
>>>>> 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??? ;)
> 
> Ugh... Then I think that we can safely replace u_phys/u_virt with u32. I have
> checked spec and it looks that it requires less changes than I expected. So,
> I can add separate patch(es) fixing that. Though I should take a look at MIPS
> part in spec too to not break its stuff. Does it make sense?
> 
> 

I *think* it does, however, I can not tell about mips - I just do not know about the requirements mips does set:)

rgds,
toomas