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

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

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

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?

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