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

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Julien Grall <julien.grall@xxxxxxxxxx> 08/17/15 6:27 PM >>>
>On 17/08/2015 08:33, Jan Beulich wrote:
>>>>> On 14.08.15 at 16:59, <shannon.zhao@xxxxxxxxxx> wrote:
>>> b) Create EFI_MEMORY_DESCRIPTOR table. This will add memory start and
>>> size information of Dom0. And Dom0 will get the memory information
>>> through this EFI table.
>>
>> To some degree the same applies here: While I see that you have no
>> legacy vehicle like x86's E820, I also don't see how Dom0 - not being
>> able to make EFI boot or runtime services calls - would get hold of this
>> table. And if a non-EFI mechanism is to be used here, using the EFI
>> data structure would turn out to be just an arbitrary (or convenience)
>> decision, not something inherently required. Which I think should be
>> said explicitly if so, rather than leaving the reader guess.
>
>It's not an arbitrary decision, when UEFI stub in Linux is using device 
>tree properties to pass the UEFI table to the kernel ([1]).
>
>When booting on Xen with ACPI, dom0 will use the non-EFI entry point. 
>The easiest way to pass the memory information to Linux is using the 
>UEFI DT properties.

In which case it is even more arbitrary to use the EFI data structure to
convey memory information (instead of expressing it in plain DT, which is
how I blindly assume non-EFI does it). Of course there's the small chance
that "UEFI DT properties" implies a certain binary format, but it's still odd
for a non-EFI entry point to assume EFI properties to be there...

Jan


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