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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.08.15 at 09:35, <zhaoshenglong@xxxxxxxxxx> wrote:
> Hi Jan,
> 
> On 2015/8/18 13:14, Jan Beulich wrote:
>>>>> Shannon Zhao <zhaoshenglong@xxxxxxxxxx> 08/18/15 5:46 AM >>>
>>> On 2015/8/17 23:33, Jan Beulich wrote:
>>>>>>> On 14.08.15 at 16:59, <shannon.zhao@xxxxxxxxxx> 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.

While this makes it look even more hacky, it doesn't answer the
question.

Jan


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