[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

Hi Shannon,

On Tue, Aug 4, 2015 at 3:43 PM, Shannon Zhao <zhaoshenglong@xxxxxxxxxx> wrote:
> This document is going to explain the design details of Xen booting with
> ACPI on ARM. Maybe parts of it may not be appropriate. Any comments are
> welcome.
> To Xen itself booting with ACPI, this is similar to Linux kernel except
> that Xen doesn't parse DSDT table. So I'll skip this part and focus on
> how Xen prepares ACPI tables for DOM0 and how Xen passes them to DOM0.
> 1)copy and change some EFI and ACPI tables.
>   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.
>   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.

Are the tables above EFI tables and all the tables below ACPI tables?

>   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, so DOM0 can call hypercall to get
>      some informations for booting necessity, such as grant tab start
>      address and size. Change header revison, length and checksum as
>      well.
>   d) Copy GTDT table. Set non_secure_el2_interrupt and
>      non_secure_el2_flags to 0 to mask EL2 timer for DOM0.

Is this necessary, doesn't Linux notice that it's booted in EL1 and
will ignore everything related to EL2?

>   e) Copy MADT table. According to the value of dom0_max_vcpus to change
>      the number GICC entries.
>   f) 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.
>   g) Copy XSDT table. Add a new table entry for STAO and change other
>      table's entries.
>   h) Change the value of xsdt_physical_address in RSDP table.
>   i) The reset of tables are not copied or changed. They are reused

s/reset/rest/ ?



Xen-devel mailing list



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