Message-ID: <alpine.DEB.2.02.1502110704420.29696@kaball.uk.xensource.com>
Date:	Wed, 11 Feb 2015 07:07:45 +0000
From:	Stefano Stabellini <stefano.stabellini@...citrix.com>
To:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
CC:	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	Mark Rutland <mark.rutland@....com>,
	"hanjun.guo@...aro.org" <hanjun.guo@...aro.org>,
	"graeme.gregory@...aro.org" <graeme.gregory@...aro.org>,
	Leif Lindholm <leif.lindholm@...aro.org>,
	Mark Langsdorf <mlangsdo@...hat.com>,
	"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Will Deacon <Will.Deacon@....com>,
	"wangyijing@...wei.com" <wangyijing@...wei.com>,
	Rob Herring <robh@...nel.org>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	Jonathan Corbet <corbet@....net>,
	Timur Tabi <timur@...eaurora.org>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	Charles Garcia-Tobin <Charles.Garcia-Tobin@....com>,
	"phoenix.liyi@...wei.com" <phoenix.liyi@...wei.com>,
	Robert Richter <rric@...nel.org>,
	Jason Cooper <jason@...edaemon.net>,
	Arnd Bergmann <arnd@...db.de>,
	Marc Zyngier <Marc.Zyngier@....com>,
	"jcm@...hat.com" <jcm@...hat.com>, Mark Brown <broonie@...nel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Matt Fleming <matt.fleming@...el.com>,
	Ashwin Chaugule <ashwinc@...eaurora.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
	Sudeep Holla <Sudeep.Holla@....com>,
	Olof Johansson <olof@...om.net>,
	Ian Campbell <ian.campbell@...rix.com>,
	Julien Grall <julien.grall@...aro.org>
Subject: Re: [PATCH v8 08/21] dt / chosen: Add linux,uefi-stub-generated-dtb
 property

On Wed, 11 Feb 2015, Ard Biesheuvel wrote:
> > Given that Dom0 is not booted via EFI but as zImage, how are we going to
> > pass the two EFI table pointers to Linux? Via Device Tree? It doesn't
> > look like a great improvement to me.
> >
> 
> The EFI system table and memory map pointers shall be passed to the
> kernel in the exact same way as the stub does: via the /chosen node.
> This is currently documented in Documentation/arm/uefi.txt but it
> should be promoted to a proper binding.

Ah, right.


> > Generating those two EFI tables shouldn't be a problem though.
> >
> >
> 
> Good.
> 
> >> As this basically promotes the stub<->kernel interface to an external
> >> ABI, the current documentation about the /chosen node properties
> >> should also be promoted to a proper binding, with the above mandated
> >> minimal subset added as well.
> >>
> >> There are some minimal changes required to the current kernel code to
> >> adhere to the above: primarlly to deal with a NULL runtime services
> >> pointer, which is arguably an improvement anyway.
> >
> > This is not needed, if not for the first generation of patches
> >
> >
> 
> It is needed: the UEFI code needs to understand that the runtime
> pointer in the EFI system table may be NULL, in which case no virtual
> remapping or installation of the runtime services should take place.
> Whether Xen ends up installing its own runtime services is a separate
> matter.
> 
> >> Topic #2: how to identify an 'empty' DTB
> >>
> >> The proposed policy regarding whether DT or ACPI should be preferred
> >> if both methods are available hinges on being able to identify a DTB
> >> as containing a platform description or not. One suggested way of
> >> doing this is to make the stub add a /chosen node property that
> >> indicates that it didn't receive a DTB from the firmware, nor loaded
> >> one from the file system, but created an empty one from scratch.
> >>
> >> Considering the previous topic, i.e., the promotion of the
> >> stub<->kernel interface to external ABI, we should not be frivolous
> >> about adding new properties, and adding a 'stub-generated-dtb'
> >> property should be avoided if there is a better way to deal with this.
> >> Also, e.g., when booting via GRUB, it may in fact be GRUB and not the
> >> stub that creates the DTB (when booting with an initrd, for instance)
> >> so GRUB would have to be modified as well. (If not, simply adding a
> >> initrd= property to the command line would result in the kernel
> >> preferring DT over ACPI all of a sudden, which surely, we all agree is
> >> undesirable behavior)
> >>
> >> So instead, we propose to use a heuristic to decide whether a DTB
> >> should be considered empty or not:
> >> If /chosen is the only level 1 node in the tree, the DTB is empty,
> >> otherwise it is not.
> >>
> >> This can be trivially implemented into the existing EFI early FDT
> >> discovery code, and does not require any other changes to the stub or
> >> GRUB.
> >>
> >> Please, could those affected by this comment whether this is feasible
> >> or not? Other comments/remarks also highly appreciated, of course,
> >
> > Wouldn't it make sense to use the same interface between Xen and Dom0
> > and between stub and kernel?
> 
> That is exactly the point: the stub communicates the EFI entry points
> (system table and memmap) via the device tree. If you are not booting
> via UEFI, there is no way you can execute the stub, so Xen needs to
> add those properties to the /chosen node directly, and make them point
> to data that the UEFI layer can understand.

OK, it looks like the right way of doing it to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists