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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.08.15 at 14:13, <zhaoshenglong@xxxxxxxxxx> wrote:
> 1. Create minimal DT to pass required information to Dom0
> ----------------------------------------------------------
> Since there are no legacy interfaces like x86 for Dom0 to get the
> booting required information on ARM, here we use the minimal DT which is
> used by UEFI stub communicating with Linux kernel as well.
> 
> The UEFI stub is a feature that extends the Image/zImage into a valid
> UEFI PE/COFF executable, including a loader application that makes it
> possible to load the kernel directly from the UEFI shell, boot menu, or
> one of the lightweight bootloaders like Gummiboot or rEFInd.
> 
> The kernel image built with stub support remains a valid kernel image
> for booting in non-UEFI environments and the UEFI stub will be jumped
> for non-UEFI environments.

Isn't this backwards? I.e. ...

> When booting in UEFI mode, the UEFI stub will create a minimal DT in
> order to pass the command line and other informations (such as the EFI
> memory table) to the kernel. And when booting with ACPI, kernel will get
> command line, ACPI root table address and memory map information from
> the minimal DT. Also, it will check if the DT contains only the /chosen
> node to know whether it boots with DT or ACPI.
> 
> In addition, the current names of these properties with a "linux,"
> prefix in the minimal DT are Linux specified. It needs to standardize
> them so that other OS(such as FreeBSD) could reuse them in the future.
> So we drop the "linux," prefix of UEFI parameters and change the names
> in Linux kernel as well.

... wouldn't it make more sense to leave the generation of these
Linux-specific tags to Linux (and allow them to continue to be Linux
specific), by the same or a second, parallel (Xen) stub? This would
then also move at least some of the awkward table creation (and
ideally also copying) to that stub.

> All these tables will be copied to Dom0 memory except that the reused
> tables(DSDT, SPCR, GTDT, etc) will be mapped to Dom0.

I continue to be puzzled by this - all of the tables should be in identical
kinds of memory, no matter whether they get mapped or copied. Yet
copying to Dom0 memory to me implies memory owned by Dom0 (and
how the kernel knows to not use it as "normal" RAM is left unsaid),
while mapping to me implies memory _not_ owned by Dom0 (much
like x86's E820 reserved type or UEFI's EfiReservedMemoryType).

Jan

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