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

[Roy Franz <roy.franz@xxxxxxxxxx>]

On Thu, Oct 30, 2014 at 10:57 AM, Daniel Kiper <daniel.kiper@xxxxxxxxxx> wrote:
> On Wed, Oct 29, 2014 at 07:21:23PM -0700, Roy Franz wrote:
>> On Wed, Oct 29, 2014 at 9:55 AM, Daniel Kiper <daniel.kiper@xxxxxxxxxx> 
>> wrote:
>> > On Wed, Oct 29, 2014 at 03:26:40PM +0000, Ian Campbell wrote:
>> >> On Wed, 2014-10-29 at 13:44 +0100, Daniel Kiper wrote:
>> >> > On Tue, Oct 28, 2014 at 08:23:48PM -0700, Roy Franz wrote:
>> >> > > 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.
>> >> >
>> >>
>> >> It would be a bug to release Xen on ARM 4.5 with broken handling of the
>> >> provision of the command line when booted via EFI.
>> >
>> > What is wrong with current implementation? I thought that it works
>> > in the same way on x86 and ARM. However, maybe I missing something.
>> >
>> > Daniel
>>
>> I'll try to provide a brief summary.
>
> Thanks!
>
>> Currently, when booted from GRUB, arm64 EFI Xen:
>> 1) processes the EFI command line for EFI related options (-basevideo,
>> etc), ie those before the "--"
>> 2) expects the Xen commandline to be in the GRUB provided FDT.
>> Anything past a "--" on the
>>     EFI commandline that would be given to Xen when booted natively
>> from EFI is ignored.
>>
>>
>> The GRUB work to support EFI Xen booting on arm64 is in progress, and
>> when Leif was reviewing
>> the code he noticed that this diverged from how EFI Linux was booted.
>> EFI Linux takes it's commandline
>> via the EFI commandline - GRUB does not put it in the FDT.  For the
>> EFI case, having both Xen and Linux
>> accept their commandlines the same way allows more shared code in
>> GRUB.  This is what motivated this
>> patch to change where the commandline was taken from.
>>
>> The discussion of this patch brought up the related issue of how EFI
>> boot code specific options, and the
>> handling of the "--" separator.  This I think has been resolved -
>> there is no use for EFI boot specific options
>> when booting from GRUB, as the EFI boot code should not do anything
>> that requires configuration.  Therefore
>> there is no "--" required, and GRUB just deals with the Xen
>> commandline.  (Note that there are some small changes
>> required to remove some code from the GRUB boot case.)
>>
>> So the open question is, when booted from GRUB (or other bootloader),
>> should Xen get it's commandline via the EFI
>> commandline, or via the MB2 protocol?  (and for arm64, this means the
>> FDT based multiboot.)  I felt that the shared code
>> in GRUB was a reasonable reason to follow what Linux did in the EFI case.
>
> After reading some GRUB2 code it looks that on ARM64 Linux Kernel PE image
> (ARM64 GRUB2 does not accept Linux Kernel in other formats) is executed as
> regular EFI application. It means that all arguments for kernel itself are
> found in usual place.
Yes, and here for a PE application the usual place is the EFI command line.


> However, arguments for initrd and ramdisk are passed
> via FDT. After reading your email I realized that you are going in the same
> direction. Am I right?
Yes

> 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
confuses/complicates these discussions.  The open issue of "is the EFI command
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
is more important than following what Linux does, so I'm dropping that
suggestion.

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.
2) the Xen commandline is provided to Xen in the multiboot2/FDT data
3) The Xen EFI configuration file is not used
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.

I think aligning on the above issues for both architectures in the EFI
would be a good
thing.
The existing arm64 implementation already does 2 and 3 from above. 1 and 4 would
require some minor changes, and I think the EFI booting documentation
should be update
to note that it does not describe EFI booting via GRUB.

>
> By the way, as I saw GRUB2 for ARM is completely different thing. Are
> you going to support loading Xen using GRUB2 on ARM EFI platforms?
Yes, this is currently being worked on by Leif and Fu, and this is expected
to be the typical boot method on those platforms.

>
> I do not know ARM stuff well so please correct me if I am wrong.
>
> Daniel

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