[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 04:54:17PM -0700, Roy Franz wrote:
> On Thu, Oct 30, 2014 at 3:18 PM, Daniel Kiper <daniel.kiper@xxxxxxxxxx> 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@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.
>
> 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.

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