Re: [Xen-devel] [GRUB2 PATCH v4 3/4 - FOR REVIEW ONLY] multiboot2: Do not pass memory maps to image if EFI boot services are enabled

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Tue, Mar 15, 2016 at 07:46:46PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 15, 2016 at 04:26:00PM +0100, Daniel Kiper wrote:
> > Do not pass memory maps to image if it asked for EFI boot services.
>
> .. I would change this sentence a bit.
>
> If image requested EFI boot services then skip multiboot2 memory maps.
>
> > Main reason for not providing maps is because they will likely be
> > invalid. We do a few allocations after filling them, e.g. for relocator
> > needs. Usually we do not care as we would already finish boot services.
>
> s/would already finish/would have finished/ ?
>
> > If we keep boot services then it is easier to not provide maps. However,
>
> s/easier/safer?/
>
> > if image needs memory maps and they are not provided by bootloader then
> > it should get them itself just before ExitBootServices() call.
>
> s/them// ?
>
> That is making an assumption that the user of Multiboot2 + EFI will
> do this. Which is OK since only Xen is using it.. but is this
> inline with the spec? Can you ignore not providing this information?

AIUI, spec does not require that anything must be provided. Of course
on every platform GRUB2 should provide minimal set of system information
to properly boot loaded image. However, docs does not say which set make
sense or not. This is role of image to know what it requires to properly
run on a given platform. And I think that it make sense.

> That aside - why not sync the multiboot memory map with what
> the EFI one will be? Or is it too to complex to move the memory map
> creation to a later phase of the bootup?

IIRC, GRUB2 does some allocations after getting memory map and it is
quite complicated to change that.

> Wish there was some multboot memory map flag indicating 'STALE-CHECK-EFI'..

Why provide map which is invalid and must be verified with something else?
Let's ignore (do not provide) invalid data and use correct one without
any additional (unneeded) checks.

Daniel

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