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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

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


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