[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 2015/8/27 15:52, Jan Beulich wrote:
On 27.08.15 at 02:37, <julien.grall@xxxxxxxxxx> 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

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?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.