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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.08.15 at 15:50, <shannon.zhao@xxxxxxxxxx> wrote:
> On 2015/8/27 15:52, Jan Beulich wrote:
>> 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.

A made up system table would (as said before) be fine with me too.
Just not a clone of the host one.

> 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.

I'd strongly advise against such hackery - it will get you (and Xen)
into the bad firmware corner. EFI without runtime services doesn't
exist. And runtime services code/data not marked as such are a
firmware bug (sadly existing in reality on the x86 side). But remember
that under Xen the Dom0 kernel mustn't care about runtime services
(other than wanting to be able to invoke them through hypercalls).

Jan


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