[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.