| Message ID | 1480020010-18421-6-git-send-email-daniel.kiper@oracle.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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
> 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
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.
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
> 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
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
> 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
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
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(-)