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@xxxxxxxxxx>
> > > > ---
> > > > 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:
> > > >
> > > > 1. 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.
> > > > 2. 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
--
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
