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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.10.14 at 04:23, <roy.franz@xxxxxxxxxx> 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:
>>>  My understanding
>>> is that for arm64 servers all the distros want to use GRUB to boot, as
>>> that is primarily how
>>> things work now, even though UEFI provides boot menu support directly.
>>> So for arm64 we want
>>> to support booting EFI both directly and using GRUB.  While there is
>>> no need now to control the
>>> behavior of the EFI application portion of Xen when booting via GRUB I
>>> think this would be useful to support.
>>
>> With the goal/purpose of what?
> Are you referring to using GRUB with EFI, or to being able to pass EFI 
> specific
> arguments to the EFI code in Xen?

And I don't see how this counter question relates to the original one.

>> 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.

There are two ways to communicate command line arguments under
GrUB: The MB2 way and the EFI way. I don't see why we would want/
need to honor the ones coming the EFI way when (supposedly) the
same ones get passed via MB2.

>> 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).
> 
> 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.)
> * 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.

Yes.

> 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.
>   Jan - it was unclear to me which of these you favor.

The natural (to GrUB) one - MB2 (or FDT if that's the MB2 equivalent
on ARM). I'm not sure about Linux on ARM, but Linux on x86 gets
special treatment by GrUB anyway, and Xen (being an MB client)
clearly shouldn't be treated like Linux. In fact I've always been
viewing it as at least conceptually bogus for Linux to be a one-off
in GrUB (as opposed to e.g. lilo, which is specifically a loader for
Linux).

> * 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.

How would that be useful, as that would mean no Dom0? Brief
inspection of ARM code doesn't show an equivalent of x86's

    /* Check that we have at least one Multiboot module. */
    if ( !(mbi->flags & MBI_MODULES) || (mbi->mods_count == 0) )
        panic("dom0 kernel not specified. Check bootloader configuration.");

but I nevertheless can't see how Xen without Dom0 would be
useful on ARM either.

> 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.

I fully agree - interfaces should be stable once we release 4.5.

Jan

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