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

[Roy Franz <roy.franz@linaro.org>]

On Tue, Nov 4, 2014 at 1:49 PM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> On Thu, Oct 30, 2014 at 04:54:17PM -0700, Roy Franz wrote:
>> On Thu, Oct 30, 2014 at 3:18 PM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
>> > On Thu, Oct 30, 2014 at 12:29:05PM -0700, Roy Franz wrote:
>> >> On Thu, Oct 30, 2014 at 10:57 AM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
>> >
>> > [...]
>> >
>> >> > If yes then I can see three solutions for this issue:
>> >> >   - GRUB2 should pass e.g. --multiboot as first argument to Xen EFI
>> >> >     application and after -- all arguments for Xen itself; Xen EFI app
>> >> >     should not parse xen.cfg files in this case,
>> >> >   - GRUB2 should pass e.g. --multiboot as first argument to Xen EFI
>> >> >     application and all arguments for Xen itself (and relevant modules)
>> >> >     in FDT; Xen EFI app should not parse xen.cfg files in this case too,
>> >> >   - GRUB2 should pass all arguments to EFI application as is via standard
>> >> >     way (as GRUB2 linux loader does on ARM64); arguments for modules should
>> >> >     be passed via FDT; Xen EFI application should parse all arguments as
>> >> >     regular xen.gz; -cfg option should be changed to cfg, -basevideo option
>> >> >     should be changed to basevideo, etc. At first sight this looks as most
>> >> >     natural thing from new multiboot protocol for ARM64 definition standpoint.
>> >> >
>> >> > Anyway, I think that this thing should be be described in multiboot for ARM64
>> >> > spec as IanC earlier told.
>> >> >
>> >> > I think that this should be ARM specific solution because we will be using
>> >> > multiboot2 protocol on x86 which works on completely different way. Hmmm...
>> >> > Maybe third solution (excluding FDT of course), if we choose that one,
>> >> > should be common thing and work on any platform including x86.
>> >>
>> >> The multiboot2 on x86 and the FDT on arm64 are very different, which I think
>> >
>> > I know.
>> >
>> >> confuses/complicates these discussions.  The open issue of "is the EFI command
>> >
>> > Yep.
>> >
>> >> line used to pass the Xen command line when GRUB boots EFI Xen" applies equally
>> >> to x86 and arm64.  I think that consistency between x86/arm64 Xen in this regard
>> >
>> > No, PE image will not be executed in the same way (simple EFI application load)
>> > by GRUB2 on x86 like it happens in case of GRUB2 on ARM64. It means that I will
>> > not be entering directly via efi_start() to efi boot code when Xen will be started
>> > by GRUB2 on x86_64 EFI platform. I am going to use separate entry point. However, I am
>> > going to use most of currently existing EFI boot code too. So, as I wrote in earlier
>> > email, I suppose that both paths (GRUB2 and native EFI application) will merge somewhere
>> > quite quickly. However, I do not have the details right now. I am working on it.
>>
>> OK, this is the part I was missing.
>>
>> >
>> >> is more important than following what Linux does, so I'm dropping that
>> >> suggestion.
>> >
>> > OK.
>> >
>> >> So I'm going to propose the following which I think is in line with
>> >> your 2nd option
>> >> (I'm not familiar with the GRUB multiboot syntax, so it might not be),
>> >> and I think
>> >> is along the lines of what Jan has also suggested:
>> >>
>> >> When booting EFI Xen via GRUB (for both x86 and arm64):
>> >> 1) the EFI command line is not used by Xen, and is ignored.
>> >
>> > As I said above, multiboot2 protocol on x86 does not execute PE
>> > application as EFI application. It means that we do not have
>> > EFI command line per se.
>>
>> OK, I understand now it makes things clearer.  My assumptions where
>> wrong about how GRUB would start the PE Xen on x86, so I was asking questions
>> that didn't really make sense.
>>
>> >
>> >> 2) the Xen commandline is provided to Xen in the multiboot2/FDT data
>> >
>> > OK.
>> >
>> >> 3) The Xen EFI configuration file is not used
>> >
>> > OK.
>> >
>> >> 4) The EFI Xen boot code does not do any console/video or other initialization.
>> >>     There is no way to provide EFI boot code specific options, as it
>> >> doesn't and shouldn't
>> >>     need any.
>> >
>> > Please see comment for 1. It means that I will skip code which parse EFI
>> > application command line. Hmmm... How are you going to detect that Xen
>> > was started by GRUB2 if you in both cases entering via efi_start()?
>> > Maybe you should look for arguments in FDT first? Or check FDT for
>> > special flag which means that EFI app was executed by GRUB? Later
>> > looks better because if Xen command line will be empty then EFI
>> > application will try read one of xen.cfg files.
>>
>> The current implementation is to examine the FDT passed to Xen to see
>> if it contains any modules.  If it does, then this indicates to the
>> EFI boot code
>> that it is being run by a bootloader, and not directly from the EFI bootmanager
>> or shell.
>
> I think that it is wrong. I am able to imagine such situation in which
> only small binary is loaded to do something specific and this binary
> does not require any modules. If we do what you suggest then we must
> load an additional module which will not be used by binary itself but
> it just signals that binary was loaded by multiboot protocol. Not nice.
> That is why I am still thinking that multiboot protocol aware loader
> should put a flag in FDT telling that binary was loaded that way.
>
> I am aware that Xen have to have at least one module (kernel image for dom0)
> but I think that new protocol should be generic as much as possible and
> Xen should not be its only one user.

I think that what is being done for Xen is robust for Xen, and likely will be
for others as well.  The FDT-multiboot bindings are just a way to pass extra
module information to an application - if there are no
"multiboot,module" compatible nodes,
then the FDT-multiboot bindings are not in use.  Multiboot2 seems to
imply much more
than that - I need to investigate that a bit more so I understand how
this is done on
x86.

>
> Daniel