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

[Shannon Zhao <zhaoshenglong@huawei.com>]

Hi Jan,

On 2015/8/18 13:14, Jan Beulich wrote:
>>>> Shannon Zhao <zhaoshenglong@huawei.com> 08/18/15 5:46 AM >>>
>> On 2015/8/17 23:33, Jan Beulich wrote:
>>>>>> On 14.08.15 at 16:59, <shannon.zhao@linaro.org> wrote:
>>>> 1. Copy and change some EFI and ACPI tables
>>>> -------------------------------------------
>>>
>>> While some explanation on the reasons for this was given in the past
>>> discussion, I'm still missing a word on the "why" for each of these here.
>>>
>>>> a) Copy EFI_SYSTEM_TABLE and change the value of FirmwareVendor,
>>>> VendorGuid, VendorTable, ConfigurationTable. These changes are not very
>>>> special and it just assign values to these members.
>>>
>>> I continue to question the need for fiddling with this table, not the
>>> least because I don't see how you intend to hand it to the Dom0
>>> kernel: Are you expecting to call the kernel's ordinary EFI entry
>>> point, despite it not itself running on EFI firmware?
>>>
>> Dom0 gets UEFI info from the minimal DT when booting with UEFI.
>> And the main purpose to create a EFI_SYSTEM_TABLE is to provide the ACPI
>> table root (RSDP) address to Dom0, so it could find the ACPI table.
> 
> For that passing the configuration table would suffice. The more that Julien
> in his reply said you're not even intending to use the kernel's EFI stub. I.e.
> the question remains: How would you expect to hand the System Table
> pointer to Dom0?
> 

Oh, I realize that there is some wrong expression about
EFI_SYSTEM_TABLE. We don't copy all the EFI System Table, but only the
EFI_SYSTEM_TABLE->Hdr. And assign the value of FirmwareVendor, set
NumberOfTableEntries to 1. Create only one EFI Configuration Table to
store Root table address. The other fields of EFI System Table stay
zero. So Dom0 only gets the ACPI table through System Table, others will
be invalid.

-- 
Shannon