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

[Roy Franz <roy.franz@xxxxxxxxxx>]

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

> The EFI application portion really is
> being replaced by GrUB (or any other more advanced boot loader,
> i.e. excluding the EFI boot manager). There are pieces of efi_start()
> that serve a purpose in both environments, but that's merely
> because that function does more than just the work attributable to
> being an EFI application.
Yup.  I think the only reason to pass EFI specific arguments in the GRUB case
is if the Xen EFI boot code is doing more than just handling basic EFI
OS startup.
If Xen doesn't do this in the GRUB case, then I don't see a need for
passing arguements
to the EFI startup code from GRUB.

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

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.

Thanks,
Roy

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