[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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@xxxxxxxxxx> 
> 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.

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

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

> I think aligning on the above issues for both architectures in the EFI
> would be a good thing.

Yep.

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

Great. By the way, when I was reading 
http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot
it was not obvious for me that multiboot on ARM64 will require PE image
and it will be started as generic EFI application but via GRUB2 (and
all arguments will be in FDT). Could you add this thing there and
in other related docs?

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

Doest it mean that multiboot on ARM and ARM64 will work in the same way?
Will it just execute PE image as EFI application and it will look for
arguments in FDT?

Daniel

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.