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

[Shannon Zhao <shannon.zhao@linaro.org>]

On 2015/8/27 15:52, Jan Beulich wrote:
>>>> On 27.08.15 at 02:37, <julien.grall@citrix.com> wrote:
>> On 20/08/2015 19:25, Shannon Zhao wrote:
>>> On 2015/8/20 22:06, Jan Beulich wrote:
>>>> 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.
>
> Ah, that clarifies things. Thanks.
>
>> 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.
>
> One other aspect completely left off so far is that of proper isolation:
> What x86 exposes to Dom0 is specifically limited to what Dom0 is
> supposed to know. I'm getting the impression that by exposing more
> EFI tables this is being violated just for the purpose of avoiding any
> changes to Linux. But maybe I'm misremembering, and all the extra
> tables exposed are actually fake ones rather than cloned host ones.
>

Currently we create EFI system table and EFI memory descriptor table as 
Linux requires. I think the EFI memory descriptor table is necessary. 
What we didn't reach an agreement is only the EFI system table. Yes, we 
only use the Configure table of the EFI system table to get the ACPI 
root address. As you mentioned before, it could pass only the Configure 
table to Dom0, but we should change the process of parsing the DT and 
consider the backwards compatibility.

On the other hand, as the RUNTIME service is not supported, it could 
assign the runtime service members of EFI system table invalid values 
and let Dom0 not initialize RUNTIME service(This could be done by making 
the memory attribute not be EFI_MEMORY_RUNTIME when we create the EFI 
memory descriptor table). If the RUNTIME service is supported in the 
future, it doesn't need to change the Linux again. So it could avoid 
changing back.

Jan, how do you think about this?

Thanks,
-- 
Shannon