xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Daniel Kiper <daniel.kiper@oracle.com>,
	grub-devel@gnu.org, xen-devel@lists.xenproject.org
Cc: jgross@suse.com, eric.snowberg@oracle.com, arvidjaar@gmail.com,
	phcoder@gmail.com, seth.goldberg@oracle.com
Subject: Re: [MULTIBOOT2 DOC PATCH 04/10] multiboot2: Add description of support for EFI boot services
Date: Thu, 9 Jun 2016 22:31:30 +0100	[thread overview]
Message-ID: <7f528bf6-cef9-cd71-1388-bf77da926197@citrix.com> (raw)
In-Reply-To: <1465504244-17175-5-git-send-email-daniel.kiper@oracle.com>

On 09/06/2016 21:30, Daniel Kiper wrote:
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  doc/multiboot.texi |  108 +++++++++++++++++++++++++++++++++++++++++++++++++++-
>  doc/multiboot2.h   |    2 +
>  2 files changed, 108 insertions(+), 2 deletions(-)
>
> diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> index e43df93..1583b76 100644
> --- a/doc/multiboot.texi
> +++ b/doc/multiboot.texi
> @@ -534,6 +534,62 @@ The physical address to which the boot loader should jump in order to
>  start running the operating system.
>  @end table
>  
> +@subsection EFI i386 entry address tag of Multiboot header
> +
> +@example
> +@group
> +        +-------------------+
> +u16     | type = 8          |
> +u16     | flags             |
> +u32     | size              |
> +u_virt  | entry_addr        |
> +        +-------------------+
> +@end group
> +@end example
> +
> +All of the address fields in this tag are physical addresses.
> +The meaning of each is as follows:
> +
> +@table @code
> +
> +@item entry_addr
> +The physical address to which the boot loader should jump in order to
> +start running EFI i386 compatible operating system code.
> +@end table
> +
> +This tag is taken into account only on EFI i386 platforms
> +when Multiboot image header contains EFI boot services tag.
> +Then entry point specified in ELF header and the entry address
> +tag of Multiboot header are ignored.
> +
> +@subsection EFI amd64 entry address tag of Multiboot header
> +
> +@example
> +@group
> +        +-------------------+
> +u16     | type = 9          |
> +u16     | flags             |
> +u32     | size              |
> +u_virt  | entry_addr        |
> +        +-------------------+
> +@end group
> +@end example
> +
> +All of the address fields in this tag are physical addresses.
> +The meaning of each is as follows:

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

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

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

Multiboot 2, not multiboot.

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

Again, Multiboot 2.

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

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

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

Same here.

~Andrew

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


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

      parent reply	other threads:[~2016-06-09 21:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1465504244-17175-1-git-send-email-daniel.kiper@oracle.com>
2016-06-09 20:30 ` [MULTIBOOT2 DOC PATCH 01/10] multiboot2: Remove redundant if Daniel Kiper
2016-06-09 20:30 ` [MULTIBOOT2 DOC PATCH 02/10] multiboot2: Clarify meaning of information request header tag Daniel Kiper
2016-06-09 21:14   ` Andrew Cooper
2016-06-09 20:30 ` [MULTIBOOT2 DOC PATCH 03/10] multiboot2: Fix description of EFI boot services tag Daniel Kiper
2016-06-09 20:30 ` [MULTIBOOT2 DOC PATCH 04/10] multiboot2: Add description of support for EFI boot services Daniel Kiper
2016-06-09 20:30 ` [MULTIBOOT2 DOC PATCH 05/10] multiboot2: Add description of EFI image handle tags Daniel Kiper
2016-06-09 20:30 ` [MULTIBOOT2 DOC PATCH 06/10] multiboot2: Add description of support for relocatable images Daniel Kiper
2016-06-09 21:36   ` Andrew Cooper
2016-06-10 17:36     ` Daniel Kiper
2016-06-09 20:30 ` [MULTIBOOT2 DOC PATCH 07/10] multiboot2: Say that memory maps may not be available on EFI platforms Daniel Kiper
2016-06-09 21:37   ` Andrew Cooper
2016-06-09 20:30 ` [MULTIBOOT2 DOC PATCH 08/10] multiboot2: Add C structure alignment and padding consideration section Daniel Kiper
2016-06-09 22:07   ` Andrew Cooper
     [not found]   ` <1c1e54de-2f19-20b6-b8c8-229619b95038@citrix.com>
2016-06-10 17:58     ` Daniel Kiper
2016-06-09 20:30 ` [MULTIBOOT2 DOC PATCH 09/10] multiboot2: Add me to authors Daniel Kiper
2016-06-09 20:30 ` [MULTIBOOT2 DOC PATCH 10/10] multiboot2: Bump version to 2.0 Daniel Kiper
     [not found] ` <1465504244-17175-2-git-send-email-daniel.kiper@oracle.com>
2016-06-09 21:02   ` [MULTIBOOT2 DOC PATCH 01/10] multiboot2: Remove redundant if Andrew Cooper
     [not found] ` <1465504244-17175-5-git-send-email-daniel.kiper@oracle.com>
2016-06-09 21:31   ` Andrew Cooper [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7f528bf6-cef9-cd71-1388-bf77da926197@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=arvidjaar@gmail.com \
    --cc=daniel.kiper@oracle.com \
    --cc=eric.snowberg@oracle.com \
    --cc=grub-devel@gnu.org \
    --cc=jgross@suse.com \
    --cc=phcoder@gmail.com \
    --cc=seth.goldberg@oracle.com \
    --cc=xen-devel@lists.xenproject.org \
    --subject='Re: [MULTIBOOT2 DOC PATCH 04/10] multiboot2: Add description of support for EFI boot services' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).