grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
From: Andrei Borzenkov <arvidjaar@gmail.com>
To: Daniel Kiper <daniel.kiper@oracle.com>,
	grub-devel@gnu.org, xen-devel@lists.xenproject.org
Cc: andrew.cooper3@citrix.com, eric.snowberg@oracle.com,
	jgross@suse.com, konrad.wilk@oracle.com, phcoder@gmail.com,
	seth.goldberg@oracle.com
Subject: Re: [MULTIBOOT2 DOC PATCH v2 05/11] multiboot2: Add description of support for EFI boot services
Date: Mon, 28 Nov 2016 20:53:51 +0300	[thread overview]
Message-ID: <cc3a5cd6-4ff9-af12-b0e9-5fcd1c746bdd@gmail.com> (raw)
In-Reply-To: <1480020010-18421-6-git-send-email-daniel.kiper@oracle.com>

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.



  parent reply	other threads:[~2016-11-28 17:54 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-24 20:39 [MULTIBOOT2 DOC PATCH v2 00/10] multiboot2: Update documentation Daniel Kiper
2016-11-24 20:40 ` [MULTIBOOT2 DOC PATCH v2 01/11] multiboot2: Rename Multiboot to Multiboot2 Daniel Kiper
2016-11-28 18:06   ` Andrei Borzenkov
2016-11-29  8:45     ` Daniel Kiper
2016-11-24 20:40 ` [MULTIBOOT2 DOC PATCH v2 02/11] multiboot2: Replace redundant if with the Daniel Kiper
2016-11-24 20:40 ` [MULTIBOOT2 DOC PATCH v2 03/11] multiboot2: Clarify meaning of information request header tag Daniel Kiper
2016-11-24 20:40 ` [MULTIBOOT2 DOC PATCH v2 04/11] multiboot2: Fix description of EFI boot services tag Daniel Kiper
2016-11-24 20:40 ` [MULTIBOOT2 DOC PATCH v2 05/11] multiboot2: Add description of support for EFI boot services Daniel Kiper
2016-11-24 21:47   ` Toomas Soome
2016-11-28 15:46     ` Daniel Kiper
2016-11-28 16:24       ` Toomas Soome
2016-11-28 17:53   ` Andrei Borzenkov [this message]
2016-11-29  9:08     ` Daniel Kiper
2016-11-29  9:39       ` Toomas Soome
2016-11-29 10:09         ` Daniel Kiper
2016-11-29 10:34           ` Toomas Soome
2016-11-24 20:40 ` [MULTIBOOT2 DOC PATCH v2 06/11] multiboot2: Add description of EFI image handle tags Daniel Kiper
2016-11-28 17:59   ` Andrei Borzenkov
2016-11-29  9:18     ` Daniel Kiper
2016-11-24 20:40 ` [MULTIBOOT2 DOC PATCH v2 07/11] multiboot2: Add description of support for relocatable images Daniel Kiper
2016-11-24 20:40 ` [MULTIBOOT2 DOC PATCH v2 08/11] multiboot2: Say that memory maps may not be available on EFI platforms Daniel Kiper
2016-11-24 20:40 ` [MULTIBOOT2 DOC PATCH v2 09/11] multiboot2: Add C structure members alignment and padding consideration section Daniel Kiper
2016-11-24 20:40 ` [MULTIBOOT2 DOC PATCH v2 10/11] multiboot2: Add me to authors Daniel Kiper
2016-11-24 20:40 ` [MULTIBOOT2 DOC PATCH v2 11/11] multiboot2: Bump version to 2.0 Daniel Kiper

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=cc3a5cd6-4ff9-af12-b0e9-5fcd1c746bdd@gmail.com \
    --to=arvidjaar@gmail.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=daniel.kiper@oracle.com \
    --cc=eric.snowberg@oracle.com \
    --cc=grub-devel@gnu.org \
    --cc=jgross@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=phcoder@gmail.com \
    --cc=seth.goldberg@oracle.com \
    --cc=xen-devel@lists.xenproject.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).