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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
