Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 2

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-08-12 at 11:48 +0100, Stefano Stabellini wrote:
> On Wed, 12 Aug 2015, Andrew Turner wrote:
> > On Wed, 12 Aug 2015 10:21:55 +0100
> > Julien Grall <julien.grall@xxxxxxxxxx> wrote:
> > 
> > > Hi,
> > > 
> > > (Cc Andrew Turner who worked on the ACPI port for FreeBSD ARM64)
> > > 
> > > On 12/08/2015 09:52, Ian Campbell wrote:
> > > > On Wed, 2015-08-12 at 11:04 +0800, Shannon Zhao wrote:
> > > > > Hi Julien,
> > > > > 
> > > > > On 2015/8/12 0:19, Julien Grall wrote:
> > > > > > Hi Shannon,
> > > > > > 
> > > > > > On 07/08/15 03:11, Shannon Zhao wrote:
> > > > > > > 2. Create minimal DT to pass required information to Dom0
> > > > > > > ----------------------------------------------------------
> > > > > > > The minimal DT mainly passes Dom0 bootargs, address and size 
> > > > > > > of
> > > > > > > initrd
> > > > > > > (if available), address and size of uefi system table, 
> > > > > > > address
> > > > > > > and size
> > > > > > > of uefi memory table, uefi-mmap-desc-size and uefi-mmap-desc
> > > > > > > -ver.
> > > > > > > 
> > > > > > > An example of the minimal DT:
> > > > > > > / {
> > > > > > >      #address-cells = <2>;
> > > > > > >      #size-cells = <1>;
> > > > > > >      chosen {
> > > > > > >          bootargs = "kernel=Image console=hvc0
> > > > > > > earlycon=pl011,0x1c090000
> > > > > > > root=/dev/vda2 rw rootfstype=ext4 init=/bin/sh acpi=force";
> > > > > > >          linux,initrd-start = <0xXXXXXXXX>;
> > > > > > >          linux,initrd-end = <0xXXXXXXXX>;
> > > > > > >          linux,uefi-system-table = <0xXXXXXXXX>;
> > > > > > >          linux,uefi-mmap-start = <0xXXXXXXXX>;
> > > > > > >          linux,uefi-mmap-size = <0xXXXXXXXX>;
> > > > > > >          linux,uefi-mmap-desc-size = <0xXXXXXXXX>;
> > > > > > >          linux,uefi-mmap-desc-ver = <0xXXXXXXXX>;
> > > > > > >      };
> > 
> > Would it be possible to add a stdout property and node for the hvc0
> > device? It would help FreeBSD as we use this to find the kernel
> > console. We check for the stdout-path, linux,stdout-path, stdout,
> > stdin-path, and stdin properties, in that order, with the first
> > property selected as the console. If none are found we fall back to
> > searching for a serial0 device. You can see how we find the device at
> > [1].
> > 
> > > > > > > };
> > > > > > > 
> > > > > > > For details loook at
> > > > > > > https://github.com/torvalds/linux/blob/master/Documentation/a
> > > > > > > rm/uefi.
> > > > > > > txt
> > > > > > 
> > > > > > AFAICT, the device tree properties in this documentation are 
> > > > > > only
> > > > > > used in order to communicate between the UEFI stub and Linux.
> > > > > > 
> > > > > > This means that those properties are not standardize and can
> > > > > > change at any time by Linux folks. They don't even live in
> > > > > > Documentation/devicetree/
> > > > > > 
> > > > > > I would also expect to see the same needs for FreeBSD running 
> > > > > > as
> > > > > > DOM0 with ACPI.
> > > > > > 
> > > > > I'm not very clear about how FreeBSD communicates with UEFI. And
> > > > > when booting with DT, how does FreeBSD communicate with UEFI? Not
> > > > > through these properties?
> > 
> > FreeBSD has a tool called loader.efi. It gets loaded by UEFI, and knows
> > how to communicate with it. It then loads the kernel and reads any
> > important data the kernel may need. Finally it puts this data into a
> > format the kernel understands, exits the boot services, and boots the
> > kernel. The kernel never communicates with UEFI, we have loaded any
> > data we need (however this may change in the future).
> > 
> > In the case of the memory may loader.efi calls GetMemoryMap from
> > EFI_BOOT_SERVICES. It then passes this data directly to the kernel for
> > the kernel to parse in the early boot code.
> > 
> > > > 
> > > > These properties are in effect a Linux internal interface defined
> > > > between the "Linux UEFI stub" and the "Linux kernel proper". The
> > > > stub and the kernel are notionally separate entities, although they
> > > > are in the same tree etc there is a well defined transition/entry
> > > > point between the two. Since they are in the same tree even though
> > > > they are in theory "separate" I expect they will tend to co-evolve.
> > > > 
> > > > IIRC we discussed with some of the maintainers (at Connect?) making
> > > > this a more formal interface, i.e. exposing the entry point to
> > > > "Linux kernel proper" which understands these properties to other
> > > > than just the "Linux UEFI stub" specifically to external entities
> > > > such as Xen.
> > > > 
> > > > Probably part of this work needs to formalise that, such as by
> > > > moving this binding into the proper external bindings dir.
> > > > 
> > > > At which point BSD can (hopefully!) choose to support the same
> > > > interface.
> > 
> > What are the advantages of these bindings over the existing UEFI calls
> > to get the memory map?
> 
> The UEFI calls couldn't be used because ExitBootServices has already
> been called.
> 
> The Linux UEFI stub is a bit like your loader.efi, except that is part
> of the kernel.

Strictly it is considered a separate thing, much like loader.efi, despite
where it lives e.g. it is self contained and not allowed to call into the
kernel proper except via the formal interface provided for the hand-off.

That might seem like semantic quibbling, but I just want to clarify that
the Linux and BSD approaches here are basically the same.

Given that these device tree bindings are really just Linux's equivalent of
the "a format the kernel understands" which BSD uses as described above. I
don't know what format BSD uses, Linux just happened to have a DTB library
handy...

>  These bindings are used to pass data from the Linux UEFI
> stub to the kernel proper, after ExitBootServices is called.
> 
> We plan to use the same bindings in Xen to pass data to the Dom0 kernel,
> again after ExitBootServices is called (by Xen in this case).
> 
> The question is whether FreeBSD could support these bindings too.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel