[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [MULTIBOOT2 DOC PATCH v2 05/11] multiboot2: Add description of support for EFI boot services
> On 28. nov 2016, at 17:46, Daniel Kiper <dkiper@xxxxxxxxxxxx> wrote: > > Hi Toomas, > > Thank you for comments. > > On Thu, Nov 24, 2016 at 11:47:48PM +0200, Toomas Soome wrote: >> There is still the same confusion as with entry address tag 7; the diagram >> has > > I suppose that you thought about tag type 3. > Yes, sorry:) >> u_virt, yet the text does claim it is physical address. Sure, it is assumed >> the >> identity mapping, but still those names are creating confusion. > > If yes then I agree that u_virt should be changed to u_phys. Though maybe in > longterm we should define tags for every architecture separately with types > specific for a given architecture. Then we should avoid most of such > confusions. > I hope… > >> Moreover, the EFI32 and EFI64 have different address sizes (32 versus 64 >> bit), >> yet there is the same type: u_virt - so it hints the upper part of the 64bit >> address is ignored, but its not really clear from the text??? > > It is clear that it should be u_phys or u32 for EFI i386. Though I am not sure > about EFI amd64 right now. Potentially it could be u64. However, I assume (at > least right now; and current GRUB implementation works in that way) that the > boot > loader cannot put any part of an image higher than 4 GiB - 1 (well, I agree > that > it should be mentioned in spec). Even on EFI amd64 platform. This is because > still > some of the image boot code can be executed in 32-bit mode. We have such > situation > in Xen. So, from this point of view 32-bit entry_addr in tag type 9 is > sufficient. > Though I can agree that we should anticipate support for full 64-bit images. > I think that it is possible (but not implemented yet). We should add to spec > tag > which says: yes, I am 64-bit image. Then the image may provide relevant 64-bit > equivalent tags (defined properly in spec). So, in this case we should have > in spec > another EFI amd64 tag which has 64-bit entry_addr. This way various boot code > types > (32-bit and 64-bit) may coexist without any issue in one image and boot > loader may > choose supported one. Does it make sense? > > Daniel Well, yes, I know about 4GB practical limit, and thats why I think it’s ok to use 32bit address there - just I wanted to point out that it may be good idea to have it explicitly noted. rgds, toomas _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |