[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 Wed, Nov 5, 2014 at 6:30 AM, Daniel Kiper <daniel.kiper@xxxxxxxxxx> wrote: > On Tue, Nov 04, 2014 at 02:48:59PM -0800, Roy Franz wrote: >> On Tue, Nov 4, 2014 at 1:49 PM, Daniel Kiper <daniel.kiper@xxxxxxxxxx> wrote: >> > On Thu, Oct 30, 2014 at 04:54:17PM -0700, Roy Franz wrote: > > [...] > >> >> 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 > > OK, however, lack of "multiboot,module" does not mean that image was not > loaded by multiboot aware loader on ARM64 platform. As I can see there > are also other valid FDT multiboot strings in spec, e.g. "multiboot,kernel". > They could not be used by Xen itself but it does not change anything in > boot protocol. Hence, I think that it is much easier to look for one string > or magic value which has meaning "loaded by multiboot aware loader" than > test all possible values to be sure that image was not loaded by "multiboot > aware loader". I think that this is worth further discussion, but I don't think this additional FDT node will be agreed upon and implemented in GRUB and Xen in time for any changes in 4.5. (and I don't think it is urgently needed.) Also, I know I used the term "loaded by multiboot aware loader", but this may not be the precise thing the arm64 EFI Xen boot code cares about. I think what it really cares about is whether the FDT it has been given has modules (ie dom0, initrd) already in it, or if the boot code needs to loade them based on a config file. > >> than that - I need to investigate that a bit more so I understand how >> this is done on x86. > > multiboot2 aware loader on x86 puts special magic value in %eax to > mark that image should expect multiboot2 as a boot protocol. Early > x86 code looks for this value and do all things accordingly. > > Daniel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |