On Wed, Jan 21, 2015 at 04:10:00PM +0000, Stefano Stabellini wrote:
On Wed, 21 Jan 2015, Catalin Marinas wrote:
On Tue, Jan 20, 2015 at 07:20:06PM +0000, Stefano Stabellini wrote:
On Tue, 20 Jan 2015, Hanjun Guo wrote:
How about the patch (just RFC, maybe it is horrible :) ) below:
When system supporting both DT and ACPI but firmware providing no dtb, we can use this linux,uefi-stub-generated-dtb property to let kernel know that we can try ACPI configuration data.
Signed-off-by: Hanjun Guo hanjun.guo@linaro.org
Documentation/devicetree/bindings/chosen.txt | 19 ++++++++++++++++ arch/arm64/kernel/setup.c | 34 +++++++++++++++++++++++++++- drivers/firmware/efi/libstub/fdt.c | 6 +++++ 3 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt index ed838f4..18776b9 100644 --- a/Documentation/devicetree/bindings/chosen.txt +++ b/Documentation/devicetree/bindings/chosen.txt @@ -44,3 +44,22 @@ Implementation note: Linux will look for the property "linux,stdout-path" or on PowerPC "stdout" if "stdout-path" is not found. However, the "linux,stdout-path" and "stdout" properties are deprecated. New platforms should only use the "stdout-path" property.
+linux,uefi-stub-generated-dtb property +--------------------------------------
+UEFI stub will generate this property in the chosen node to let linux kernel +know that there is no DTB provided by firmware.
+There is a use case for system supporting both DT and ACPI, when firmware +doesn't provide DT, we can try ACPI configration data to boot the system.
+Usage:
+linux,uefi-stub-generated-dtb = "true" means that it is true that the dtb +is generated by uefi stub
+or
+linux,uefi-stub-generated-dtb = "false" is the reverse.
I am sorry to have to make the discussion even more complex than already is, however we have one more use case to consider: Linux booting on Xen as Dom0.
When booting as Dom0 on ACPI hardware, Linux doesn't have access to the UEFI firmware (no EFI stub). Xen passes a small device tree blob with a chosen node, memory information and a pointer to the ACPI tables. It looks similar to the DTB passed to Linux by the EFI stub but it is generated by Xen instead.
We have two (or even three) different use cases here. One of them is a way to tell the kernel that there is no point in trying DT since it has been generated by the EFI stub and it doesn't have any SoC information. The kernel can bet on ACPI tables being present or just fail to boot. What I want to avoid is "acpi=force" parameter being part of the kernel/firmware ABI for using ACPI (whether DT is present or not).
We could call this something else ("linux,bare-dtb"?) if we want to use it in other situations but not "enable_acpi" as we don't want to move the ACPI enabling policy in the EFI stub or boot loader (or whatever generates the chosen node).
The Xen case is close to the kexec one. For the latter (I haven't looked at the current arm64 patches yet), I can see that you can pass an "acpi_rsdp" argument to the kernel with the ACPI RSDP address. I don't think that's ideal, we better have some defined DT bindings for such information in the absence of EFI. But it basically means that we'll allow ACPI on arm64 without EFI.
Good, I agree.
On Wed, 21 Jan 2015, Catalin Marinas wrote:
On Wed, Jan 21, 2015 at 03:29:52PM +0000, Jon Masters wrote:
On 01/21/2015 10:23 AM, Catalin Marinas wrote:
I have some questions for the ACPI and EFI folk:
- When booting with ACPI, are the EFI run-time services required for anything? If yes, Xen may have a bigger problem
Yes. At least for some things. For example, installing an Operating System would require that you make runtime services calls to set the BootOrder/BootNext variables, and so on. Further, we use the GetTime service and EFI based reboot to avoid having special drivers. I had those added to SBBR as requirements for that reason.
So what would a kexec'ed kernel do here? Or we usually expect it to be short lived and doesn't need reboot, nor GetTime.
Xen is slightly more problematic but I wonder whether it could run a (paravirtualised) UEFI.
As a matter of fact that's how it is done on x86: Xen exports a paravirtualized UEFI run-time services interface (drivers/xen/efi.c). Daniel Kiper (CC'ed) wrote the code that went upstream last August. There is no reason why we could not do the same on ARM.
I have done it with ARM in my mind. So, I think that you can reuse that code fairly easy. Just take look at drivers/xen/efi.c (I think that this should work on ARM without major changes) and assume arch/x86/xen/efi.c and arch/x86/xen/enlighten.c as an example of starting point.
- Could a boot loader (either kernel doing kexec or Xen) emulate the EFI system/config tables and still make them useful to the kernel but without EFI_BOOT or EFI_RUNTIME_SERVICES?
Yes. But again, without the other required pieces (including the services function pointers in the systab which are required) you'd crash soon after boot trying to make those calls.
My point was whether you can still pass information like RSDP address via EFI tables but explicitly disable runtime services so that the kernel won't try to make such calls (and crash).
I don't think that run-time services are going to be a problem for Xen, but I agree that it would be nice not to depend on them to have ACPI.
IIRC, there are relevant options in Linux Kernel and Xen to disable runtime services, however, I have not tested them.
Daniel