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

[Shannon Zhao <zhaoshenglong@xxxxxxxxxx>]

Hi Jan,

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.

Here since we don't support RUNTIME service fro Dom0 currently, we could
set the Attribute of EFI_SYSTEM_TABLE memory region to not be
EFI_MEMORY_RUNTIME or pass kernel command parameter "efi=noruntime" to
disable RUNTIME service.

>> 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.
> 
>> c) Copy FADT table. Change the value of arm_boot_flags to enable PSCI
>> and HVC. Let the hypervisor_id be "XenVMM" in order to tell Dom0 that it
>> runs on Xen hypervisor, then Dom0 could through HVM_PARAM to get some
>> informations for booting necessity, such as event-channel interrupt.
>> Change header revison, length and checksum as well.
>>
>> d) Copy MADT table. According to the value of dom0_max_vcpus to change
>> the number GICC entries.
>>
>> e) Create STAO table. This table is a new added one that's used to
>> define a list of ACPI namespace names that are to be ignored by the OSPM
>> in Dom0. Currently we use it to tell OSPM should ignore UART defined in
>> SPCR table.
>>
>> f) Copy XSDT table. Add a new table entry for STAO and change other
>> table's entries.
>>
>> g) Change the value of xsdt_physical_address in RSDP table.
> 
> Which RSDP? Under EFI the table root is to be found from the
> EFI Configuration Table.
> 
Yes, the RSDP address is stored in EFI Configure Table. And RSDP table
has a field "xsdt_physical_address" that points to the XSDT table. As we
create a new XSDT and the address of XSDT is changed, so it needs to
update the value of "xsdt_physical_address" in RSDP. So Dom0 could get
the right XSDT table rather than the old one.

Thanks,
-- 
Shannon


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