[Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 2

[Shannon Zhao <zhaoshenglong@xxxxxxxxxx>]

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.

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 grant table 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.

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 rest of tables are not copied or changed. They are reused
including DSDT, SPCR, etc.

All these tables will be copied to Dom0 memory except that the reused
tables(DSDT, SPCR, etc) will be mapped to Dom0.

2. Create minimal DT to pass required information to Dom0
----------------------------------------------------------
The minimal DT mainly passes Dom0 bootargs, address and size of initrd
(if available), address and size of uefi system table, address and size
of uefi memory table, uefi-mmap-desc-size and uefi-mmap-desc-ver.

An example of the minimal DT:
/ {
    #address-cells = <2>;
    #size-cells = <1>;
    chosen {
        bootargs = "kernel=Image console=hvc0 earlycon=pl011,0x1c090000
root=/dev/vda2 rw rootfstype=ext4 init=/bin/sh acpi=force";
        linux,initrd-start = <0xXXXXXXXX>;
        linux,initrd-end = <0xXXXXXXXX>;
        linux,uefi-system-table = <0xXXXXXXXX>;
        linux,uefi-mmap-start = <0xXXXXXXXX>;
        linux,uefi-mmap-size = <0xXXXXXXXX>;
        linux,uefi-mmap-desc-size = <0xXXXXXXXX>;
        linux,uefi-mmap-desc-ver = <0xXXXXXXXX>;
    };
};

For details loook at
https://github.com/torvalds/linux/blob/master/Documentation/arm/uefi.txt

3. Dom0 gets grant table and event channel irq information
-----------------------------------------------------------
As said above, we assign the hypervisor_id be "XenVMM" to tell Dom0 that
it runs on Xen hypervisor.

For grant table, add two new HVM_PARAMs: HVM_PARAM_GNTTAB_START_ADDRESS
and HVM_PARAM_GNTTAB_SIZE.

For event channel irq, reuse HVM_PARAM_CALLBACK_IRQ and add a new
delivery type:
val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI (ARM and ARM64
only)

When constructing Dom0 in Xen, save these values. Then Dom0 could get
them through hypercall HVMOP_get_param.

4. Map MMIO regions
-------------------
Register a bus_notifier for platform and amba bus in Linux. Add a new
XENMAPSPACE "XENMAPSPACE_dev_mmio". Within the register, check if the
device is newly added, then call hypercall XENMEM_add_to_physmap to map
the mmio regions.

5. Route device interrupts to Dom0
----------------------------------
Route all the SPI interrupts to Dom0 before Dom0 booting.


Look forward to your comments. If you think it has no problem, giving
your ack would be a big help. Then the patchset could move on. :)

Thanks,
-- 
Shannon


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