[PATCH v8 08/21] dt / chosen: Add linux,uefi-stub-generated-dtb property

On Wed, 11 Feb 2015, Ard Biesheuvel wrote:

quoted

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.

quoted

Generating those two EFI tables shouldn't be a problem though.

Good.

quoted

quoted

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.

quoted

quoted

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.