[MULTIBOOT2 DOC PATCH v3 01/13] multiboot2: Replace u_phys with u32

[MULTIBOOT2 DOC PATCH v3 01/13] multiboot2: Replace u_phys with u32

[Daniel Kiper]

u_phys is used just in two places and sometimes it may confuse reader.
Additionally, GRUB multiboot2 implementation does not use u_phys anywhere.
So, replace it with basic well defined and used in implementation u32 type.

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

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 4b92918..2bda9b7 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -299,9 +299,6 @@ little-endian, u32 is coded in little-endian.
 The type of unsigned 64-bit data. Because the target architecture is
 little-endian, u64 is coded in little-endian.
 
-@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.
 
@@ -840,8 +837,8 @@ zero-terminated UTF-8 string.
         +-------------------+
 u32     | type = 3          |
 u32     | size              |
-u_phys  | mod_start         |
-u_phys  | mod_end           |
+u32     | mod_start         |
+u32     | mod_end           |
 u8[n]   | string            |   
         +-------------------+
 @end group
@@ -850,8 +847,8 @@ u8[n]   | string            |
 This tag indicates to the kernel what boot module was loaded along with the
 kernel image, and where it can be found.
 
-The @samp{mod_start} and @samp{mod_end} contain the start and end addresses of the boot
-module itself. The @samp{string} field provides an arbitrary string to
+The @samp{mod_start} and @samp{mod_end} contain the start and end physical addresses
+of the boot module itself. The @samp{string} field provides an arbitrary string to
 be associated with that particular boot module; it is a zero-terminated
 UTF-8 string, just like the kernel command line. Typically the
 string might be a command line (e.g. if the operating system treats boot
-- 
1.7.10.4


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

[MULTIBOOT2 DOC PATCH v3 02/13] multiboot2: Replace u_virt with u32

[Daniel Kiper]

u_virt may sometimes confuse reader especially if description says something
completely different. Additionally, GRUB multiboot2 implementation does not
use u_virt anywhere. So, replace it with basic well defined and used in
implementation u32 type.

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

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 2bda9b7..7d12ab0 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -299,9 +299,6 @@ little-endian, u32 is coded in little-endian.
 The type of unsigned 64-bit data. Because the target architecture is
 little-endian, u64 is coded in little-endian.
 
-@item u_virt
-The type of unsigned data of the same size as target architecture virtual address size.
-
 @end table
 
 
@@ -407,7 +404,7 @@ and @samp{header_length}), must have a 32-bit unsigned sum of zero.
 
 @node Header tags
 @subsection General tag structure
-Tags constitutes a buffer of structures following each other padded on @samp{u_virt} size.
+Tags constitutes a buffer of structures following each other padded on @samp{u32} size.
 Every structure has following format:
 
 @example
@@ -460,10 +457,10 @@ actually be present. E.g. on a videoless system even if you requested tag
 u16     | type = 2          |
 u16     | flags             |
 u32     | size              |
-u_virt  | header_addr       |
-u_virt  | load_addr         |
-u_virt  | load_end_addr     |
-u_virt  | bss_end_addr      |
+u32     | header_addr       |
+u32     | load_addr         |
+u32     | load_end_addr     |
+u32     | bss_end_addr      |
         +-------------------+
 @end group
 @end example
@@ -511,7 +508,7 @@ assumes that no bss segment is present.
 u16     | type = 3          |
 u16     | flags             |
 u32     | size              |
-u_virt  | entry_addr        |
+u32     | entry_addr        |
         +-------------------+
 @end group
 @end example
-- 
1.7.10.4


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

[MULTIBOOT2 DOC PATCH v3 03/13] 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 7d12ab0..904c082 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
@@ -303,7 +303,7 @@ little-endian, u64 is coded in little-endian.
 
 
 @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:
 
@@ -336,17 +336,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::       
@@ -357,9 +357,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
@@ -376,7 +376,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
@@ -391,7 +391,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.
 
 
@@ -424,7 +424,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
@@ -449,7 +449,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
@@ -470,7 +470,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.
@@ -500,7 +500,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
@@ -542,7 +542,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
@@ -624,11 +624,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
@@ -651,11 +651,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}).
 
@@ -708,13 +708,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
@@ -1184,14 +1184,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
@@ -1200,7 +1200,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
@@ -1300,18 +1300,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
@@ -1320,14 +1320,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
 
 
@@ -1361,10 +1361,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
@@ -1375,7 +1375,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:
 
@@ -1392,14 +1392,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
@@ -1413,7 +1413,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 v3 04/13] 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 904c082..a9cba9b 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -419,7 +419,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 v3 05/13] 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 a9cba9b..4f838f0 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -437,15 +437,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 v3 06/13] 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 4f838f0..9af756a 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -352,6 +352,7 @@ executable header.
 * Address header tag::       
 * Console header tags::
 * Module alignment tag::
+* EFI boot services tag::
 
 @end menu
 
@@ -602,8 +603,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
@@ -616,7 +617,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 v3 07/13] multiboot2: Add description of support for EFI boot services

[Daniel Kiper]

Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
---
v3 - suggestions/fixes:
   - replace u_virt with u32
     (suggested by Andrei Borzenkov and Toomas Soome),
   - change RAX/RBX to EAX/EBX in "EFI amd64 machine state with boot
     services enabled" section,
   - describe the kernel, the modules, etc. load addresses limitation
     in "EFI amd64 machine state with boot services enabled" section,
   - replace Multiboot-compliant with Multiboot2-compliant.

v2 - suggestions/fixes:
   - clarify physical address meaning for EFI amd64
     mode with boot services enabled
     (suggested by Andrew Cooper).
---
 doc/multiboot.texi |  124 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 doc/multiboot2.h   |    2 +
 2 files changed, 126 insertions(+)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 9af756a..9f13e74 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -528,6 +528,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              |
+u32     | 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              |
+u32     | 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
 
@@ -708,6 +768,70 @@ 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
+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 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 EAX
+Must contain the magic value @samp{0x36d76289}; the presence of this
+value indicates to the operating system that it was loaded by a
+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 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.
+
+The bootloader must not load any part of the kernel, the modules, the Multiboot2
+information structure, etc. higher than 4 GiB - 1. This requirement is put in
+force because most of currently specified tags supports 32-bit addresses only.
+Additionally, some kernels, even if they run on EFI 64-bit platform, still
+execute some parts of its initialization code in 32-bit mode.
+
+Note: If at some point there is a need for full 64-bit mode support in Multiboot2
+protocol then it should be designed very carefully. Especially it should be taken
+into account that 32-bit and 64-bit mode code should coexist in an image without
+any issue. The image should have a chance to inform the bootloader that it supports
+full 64-bit mode. If it is the case then the bootloader should provide 64-bit tags
+if it is desired and possible. Otherwise 32-bit tags should be used.
+
 @node Boot information format
 @section Boot information
 @subsection Boot information format
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

Re: [MULTIBOOT2 DOC PATCH v3 07/13] multiboot2: Add description of support for EFI boot services

[Konrad Rzeszutek Wilk]

.snip..
> --- a/doc/multiboot.texi
> +++ b/doc/multiboot.texi
> @@ -528,6 +528,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             |


Would it make sense to describe what 'flags' should contain? Or at least
if there is nothing yet there mention that the value is ignored and
should be zero?

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

Re: [MULTIBOOT2 DOC PATCH v3 07/13] multiboot2: Add description of support for EFI boot services

[Daniel Kiper]

On Wed, Dec 07, 2016 at 09:33:55AM -0500, Konrad Rzeszutek Wilk wrote:
> ..snip..
> > --- a/doc/multiboot.texi
> > +++ b/doc/multiboot.texi
> > @@ -528,6 +528,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             |
>
>
> Would it make sense to describe what 'flags' should contain? Or at least
> if there is nothing yet there mention that the value is ignored and
> should be zero?

'flags' is generic field and it is described earlier in the document.

Daniel

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

[MULTIBOOT2 DOC PATCH v3 08/13] 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 9f13e74..1581220 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -1295,6 +1295,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 v3 09/13] 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 1581220..13e4e80 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -353,6 +353,7 @@ executable header.
 * Console header tags::
 * Module alignment tag::
 * EFI boot services tag::
+* Relocatable header tag::
 
 @end menu
 
@@ -679,6 +680,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
 
@@ -1323,6 +1365,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 v3 10/13] 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 13e4e80..35f2bed 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -941,6 +941,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
@@ -1092,6 +1096,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
@@ -1324,6 +1332,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 v3 11/13] 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 35f2bed..f566114 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -1398,6 +1398,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::             
@@ -1405,6 +1406,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 v3 12/13] 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 f566114..08cc5c3 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 v3 13/13] 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 08cc5c3..d20415d 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

Re: [MULTIBOOT2 DOC PATCH v3 00/13] multiboot2: Update documentation

[Konrad Rzeszutek Wilk]

On December 6, 2016 5:52:48 PM EST, Daniel Kiper <daniel.kiper@oracle.com> wrote:
>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.

Why not the master one?

>
>Here is short list of changes since v2:
>  - new patches: 01, 02,
>  - changed patches: 07.
>

How about the rename of the file? Or would it make sense to do that in some other followup patches?

Thanks!


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

Re: [MULTIBOOT2 DOC PATCH v3 00/13] multiboot2: Update documentation

[Daniel Kiper]

On Tue, Dec 06, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote:
> On December 6, 2016 5:52:48 PM EST, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> >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.
>
> Why not the master one?

Because doc lives in multiboot2 branch. I am going to
move it to master after 2.02 and then...

> >Here is short list of changes since v2:
> >  - new patches: 01, 02,
> >  - changed patches: 07.
> >
>
> How about the rename of the file? Or would it make sense
> to do that in some other followup patches?

...rename relevant files.

Daniel

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

Re: [MULTIBOOT2 DOC PATCH v3 00/13] multiboot2: Update documentation

[Konrad Rzeszutek Wilk]

On Wed, Dec 07, 2016 at 12:26:19PM +0100, Daniel Kiper wrote:
> On Tue, Dec 06, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote:
> > On December 6, 2016 5:52:48 PM EST, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> > >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.
> >
> > Why not the master one?
> 
> Because doc lives in multiboot2 branch. I am going to
> move it to master after 2.02 and then...
> 
> > >Here is short list of changes since v2:
> > >  - new patches: 01, 02,
> > >  - changed patches: 07.
> > >
> >
> > How about the rename of the file? Or would it make sense
> > to do that in some other followup patches?
> 
> ...rename relevant files.

I only had one question on #7, otherwise feel free to stick
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thank you for documenting this!
> 
> Daniel

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

Re: [MULTIBOOT2 DOC PATCH v3 00/13] multiboot2: Update documentation

[Daniel Kiper]

On Wed, Dec 07, 2016 at 09:34:30AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 07, 2016 at 12:26:19PM +0100, Daniel Kiper wrote:
> > On Tue, Dec 06, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On December 6, 2016 5:52:48 PM EST, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> > > >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.
> > >
> > > Why not the master one?
> >
> > Because doc lives in multiboot2 branch. I am going to
> > move it to master after 2.02 and then...
> >
> > > >Here is short list of changes since v2:
> > > >  - new patches: 01, 02,
> > > >  - changed patches: 07.
> > > >
> > >
> > > How about the rename of the file? Or would it make sense
> > > to do that in some other followup patches?
> >
> > ...rename relevant files.
>
> I only had one question on #7, otherwise feel free to stick
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Thanks a lot!

> Thank you for documenting this!

You are welcome!

Daniel

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

Re: [MULTIBOOT2 DOC PATCH v3 00/13] multiboot2: Update documentation

[Daniel Kiper]

On Tue, Dec 06, 2016 at 11:52:48PM +0100, Daniel Kiper wrote:
> 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.
>
> Here is short list of changes since v2:
>   - new patches: 01, 02,
>   - changed patches: 07.

If there are no more objections then I will apply this patch series at
the beginning of next week.

Daniel

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

Re: [MULTIBOOT2 DOC PATCH v3 00/13] multiboot2: Update documentation

[Daniel Kiper]

On Fri, Dec 09, 2016 at 01:57:13PM +0100, Daniel Kiper wrote:
> On Tue, Dec 06, 2016 at 11:52:48PM +0100, Daniel Kiper wrote:
> > 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.
> >
> > Here is short list of changes since v2:
> >   - new patches: 01, 02,
> >   - changed patches: 07.
>
> If there are no more objections then I will apply this patch series at
> the beginning of next week.

Applied! Happy reading...

Daniel

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

Re: [MULTIBOOT2 DOC PATCH v3 01/13] multiboot2: Replace u_phys with u32

[Andrei Borzenkov]

07.12.2016 01:52, Daniel Kiper пишет:
> u_phys is used just in two places and sometimes it may confuse reader.
> Additionally, GRUB multiboot2 implementation does not use u_phys anywhere.
> So, replace it with basic well defined and used in implementation u32 type.
> 
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  doc/multiboot.texi |   11 ++++-------
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> index 4b92918..2bda9b7 100644
> --- a/doc/multiboot.texi
> +++ b/doc/multiboot.texi
> @@ -299,9 +299,6 @@ little-endian, u32 is coded in little-endian.
>  The type of unsigned 64-bit data. Because the target architecture is
>  little-endian, u64 is coded in little-endian.
>  
> -@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.
>  

So if I understand it correctly, any address used in multiboot2 is
limited to 32 bit, so anything that is relevant to boot protocol must
reside below 4G. Is my assumption correct?



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

Re: [MULTIBOOT2 DOC PATCH v3 01/13] multiboot2: Replace u_phys with u32

[Daniel Kiper]

On Sat, Dec 10, 2016 at 08:23:15PM +0300, Andrei Borzenkov wrote:
> 07.12.2016 01:52, Daniel Kiper пишет:
> > u_phys is used just in two places and sometimes it may confuse reader.
> > Additionally, GRUB multiboot2 implementation does not use u_phys anywhere.
> > So, replace it with basic well defined and used in implementation u32 type.
> >
> > Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> > ---
> >  doc/multiboot.texi |   11 ++++-------
> >  1 file changed, 4 insertions(+), 7 deletions(-)
> >
> > diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> > index 4b92918..2bda9b7 100644
> > --- a/doc/multiboot.texi
> > +++ b/doc/multiboot.texi
> > @@ -299,9 +299,6 @@ little-endian, u32 is coded in little-endian.
> >  The type of unsigned 64-bit data. Because the target architecture is
> >  little-endian, u64 is coded in little-endian.
> >
> > -@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.
> >
>
> So if I understand it correctly, any address used in multiboot2 is
> limited to 32 bit, so anything that is relevant to boot protocol must

More or less. There are some exceptions when EFI x64 platforms come on the stage.
It is described in spec.

> reside below 4G. Is my assumption correct?

Yep. More info you can find in patch #07.

Daniel

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