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

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi,

Sorry for the late answer.

On 20/08/2015 19:25, Shannon Zhao wrote:
> On 2015/8/20 22:06, Jan Beulich wrote:
> > > > > On 20.08.15 at 14:56, <shannon.zhao@xxxxxxxxxx> wrote:
> > > On 2015/8/20 17:30, Jan Beulich wrote:
> > > > > > > On 20.08.15 at 05:41, <zhaoshenglong@xxxxxxxxxx> wrote:
> > > > > On 2015/8/19 22:05, Jan Beulich wrote:
> > > > > > > > > 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. ...
> > > > > Sorry, what do you mean here?
> > > > > It's used for backwards compatibility. The reason I mention it here is
> > > > > to explain that Xen acts as a EFI stub which creates a minimal DT and
> > > > > load kernel image. Even though the kernel image built with EFI stub
> > > > > which will be jumped, the kernel could boot well as before.
> > > > To me what you and Julien replied contradicts one another: You say
> > > > it's Xen to create these DT tags, whereas he assures me that these
> > > > tags are Linux internal ones.
> > > I think What Julien said is to explain that the DT properties are used
> > > between EFI stub and kernel image which are built together. So if we
> > > change the names in Linux, it won't break backward compatibility.
> > >
> > > I'll explain What I mean here. If not right, please fix me.
> > > Firstly, Xen doesn't offer a (complete) firmware for Dom0, so it can't
> > > load EFI stub, then EFI stub loads the kernel image. Therefore, there
> > > are no chance to create the DT which we want to use it to pass the uefi
> > > information.
> > > Secondly, we make Xen act like a EFI stub to create the DT which could
> > > pass the information to Dom0. When we load kernel image, the kernel will
> > > call efi_get_fdt_params to get the information from the DT just like the
> > > DT is created by EFI stub for kernel.
> > So can the two of you please sort out whether these are Linux
> > internal tags (which Xen has no business generating, or even
> > knowing of) or some form of publicly documented interface?
> They are Linux internal tags. But to support Xen ACPI on ARM, we just
> reuse the existing mechanism to pass the information to Dom0.
My previous mail was unclear, sorry. I was explaining the current usage 
of those properties because you seemed to be concern about the backward 
compatibility.
We'd like to formalize those properties in order to use them to pass 
information between Xen and the kernel image.
This would avoid us to create a Xen specific entry path in the kernel 
and use the non-EFI one (also used by the EFI stub) and make easier to 
support new DOM0 OS (for instance FreeBSD).
So I totally agree with Shannon mails.

Regards,

--
Julien Grall

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