[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 3

On 2015/8/18 17:11, Jan Beulich wrote:
>>>> On 18.08.15 at 10:21, <zhaoshenglong@xxxxxxxxxx> wrote:
>> On 2015/8/18 16:15, Jan Beulich wrote:
>>>>>> 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?
>> The System Table pointer will be passed to Dom0 through the minimal DT
>> property "linux,uefi-system-table".
> And this is a requirement for Linux? I.e. it can't do with just the
> Configuration Table (which architecturally would be more clean imo)?

IIUC, this is a requirement for Linux. Because when Linux parses the
minimal DT, it uses below dt_params to match the DT properties. If it
doesn't match any of them, it will fial.
See efi_get_fdt_params in drivers/firmware/efi/efi.c.

static __initdata struct {
        const char name[32];
        const char propname[32];
        int offset;
        int size;
} dt_params[] = {
        UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
        UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
        UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
        UEFI_PARAM("MemMap Desc. Size", "linux,uefi-mmap-desc-size", desc_size),
        UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)

Another choice to pass ACPI root table address is to use the kernel
parameter "acpi_rsdp". But it still needs to supply the property
"linux,uefi-system-table" in DT to make the EFI driver works. While the
value of the "linux,uefi-system-table" could be something invalid, so
Dom0 would not use the EFI System table.


Xen-devel mailing list



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