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

[Shannon Zhao <zhaoshenglong@xxxxxxxxxx>]

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.

Wait for Julien's reply.

> I'm
> not going to comment on this any further until I get consistent
> messages from both of you.
> 


>>>>>> 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).
>>>>>
>>>>
>>>> These will be described in EFI_MEMORY_DESCRIPTOR table. For Dom0 memory
>>>> range, the Type is EfiConventionalMemory. For ACPI tables whether it's
>>>> new created or reused, the Type is EfiACPIReclaimMemory. For EFI System
>>>> table and Memory Descriptor table, the Type is EfiReservedMemoryType.
>>>
>>> And Dom0 will have to figure out how to establish mappings for the
>>> two different kinds (which ought to work differently since in one case
>>> Dom0-owned memory is to be mapped, while in the other case it's
>>> Xen- [or even firmware-]owned memory)? Anyway - even without
>>> that aspect, it seems conceptually wrong to place firmware tables
>>> (even if they are fake ones) in Dom0-owned memory.
>>>
>> Here we do not want to supply Dom0 with a firmware. We just want to take 
>> advantage of the existing way to pass the information to Dom0.
>>
>> If this not right, do you have any other good ideas for this? Please 
>> share your suggestion with me.
> 
> I already said how I would see this done cleanly: Even if the tables
> are being made up, pass them in a unique, consistent way so that
> Dom0 has a unique way to access them. And the only consistent
> way I can see is pass them all in memory _not_ owned by Dom0.
> 

I'm ok with placing them in the memory not owned by Dom0. Is there some
ways to find that kind of memory space in Xen?

Thanks,
-- 
Shannon


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