Re: [Xen-devel] [PATCH V2 for-4.5] EFI: Always use EFI command line

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Tue, Oct 28, 2014 at 08:23:48PM -0700, Roy Franz wrote:
> On Tue, Oct 28, 2014 at 12:48 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> >>>> On 27.10.14 at 23:29, <roy.franz@xxxxxxxxxx> wrote:
> >> On Mon, Oct 27, 2014 at 3:55 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> >>> And anyway, only when booting from UEFI (without GrUB involved)
> >>> does anything prior to an eventual -- matter. With GrUB it shouldn't
> >>> (and hence the separator is then also pointless and should neither
> >>> get inserted nor looked for), as these options only control the EFI
> >>> application behavior of the binary. At least that's how it was
> >>> intended to be originally.
> >>>
> >> So I guess on x86 GRUB is not used to boot the EFI version of Xen?
> >
> > Correct - supporting this is what Daniel Kiper has been working on
> > for the last several months.

It looks that we we will be able to load PE image using EFI loader,
multiboot(1) and multiboot2 protocol. I did some initial tests
and everything looks promising. However, there is an open question
how to build final PE image with required properties. I have at
least two ideas how to do that I am going to present them shortly
on Xen-devel.

[...]

> > That doesn't extend to the command line though if the mechanism
> > by which GrUB communicates it to its descendants is via the Loaded
> > Image protocol rather than MB2 (albeit that seems dubious to me).
> I don't really understand what you are saying here.
>
> > But that's still only the "core" command line, not the part the EFI
> > application would see/handle prior to the first --. I.e. that part of
> > efi_start() really also should become conditional upon whether a
> > config file is being used (as well as the code leading to the
> > StdOut->SetMode() call).
> >
> > Jan
>
> If I understand you correctly, you are suggesting something along the lines 
> of:
> * If a bootloader (GRUB, etc.) is used to load EFI Xen, the bootloader
> is responsible for taking care of all of
>  the module loading and other setup such as video/console modes, and
> the EFI boot code in Xen
>  just does the EFI OS starting bits (memory map, ExitBootServices, etc.)

More or less (I am inclining to less and IIRC it was agreed during last
Xen Hackathon). I am working on this issue right now.

> * This requires some additional code in efi_start() to be
> conditionalized based on the need for
>   a config file.  (which is really whether a bootloader has loaded XEN
> vs. a native EFI load.)
>
> This resolves the whole "--" in the commandline issue - the command
> line specified in GRUB is for
> Xen itself, no options are processed by the EFI boot code.
>
>
> The two open issues I see are:
> * Should the Xen commandline be put into the MBD2/FDT, or giving in
> the EFI command line?  In the arm64 case,
> passing it in the EFI commandline is what EFI Linux does and allows
> more code sharing in GRUB.

I think that in case of Xen loaded by GRUB we should not mangle in any
way command line passed to Xen and modules. Even GRUB should not mangle
command lines. All of them should be passed and parsed as is. This way we
will be in line with current versions of multiboot protocols and GRUB.

>   Jan - it was unclear to me which of these you favor.
> * How to determine if Xen is loaded by GRUB?  For arm64, I currently
> use the presence of a module in the
> FDT provided.  Is it possible/useful to boot Xen without any modules?
> If it is then a more robust mechanism
> needs to be used.

efi_start() should be called only by EFI loader. There should be
separate entry point in EFI init code for multiboot protocol. It
should take into account that we have some knowledge from GRUB
(or any mutliboot protocol aware loader) and act as required.
However, I suppose that somewhere, probably quite early, both
code paths (let's call it EFI and GRUB) will merge. Currently
I am working on this and I hope that I will be able to post
something in November.

> If possible I'd like to get this settled so that adjustments to the
> EFI boot code can be made for the 4.5 release. It would be nice to
> have the EFI boot from GRUB interface be settled and not change
> after the release.

Hmmm... Do you mean 4.6? 4.5 is in freezing state so only bugfixes are allowed.

Daniel

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