From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roy Franz Subject: Re: [PATCH V2 for-4.5] EFI: Always use EFI command line Date: Tue, 4 Nov 2014 14:48:59 -0800 Message-ID: References: <544F58770200007800042ADA@mail.emea.novell.com> <20141029124411.GA3467@olila.local.net-space.pl> <1414596400.29580.12.camel@citrix.com> <20141029165526.GB3467@olila.local.net-space.pl> <20141030175714.GF3467@olila.local.net-space.pl> <20141030221857.GA16923@olila.local.net-space.pl> <20141104214952.GL16923@olila.local.net-space.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20141104214952.GL16923@olila.local.net-space.pl> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Daniel Kiper Cc: Ian Campbell , tim , Leif Lindholm , xen-devel , Stefano Stabellini , Jan Beulich , Fu Wei List-Id: xen-devel@lists.xenproject.org On Tue, Nov 4, 2014 at 1:49 PM, Daniel Kiper 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 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 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