RE: ACPI/UEFI support for Xen/ARM status?

[Henry Wang <Henry.Wang@xxxxxxx>]

Hi Elliott,

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of
> Elliott Mitchell
> Sent: Friday, November 12, 2021 12:28 PM
> To: Stefano Stabellini <sstabellini@xxxxxxxxxx>; Julien Grall <julien@xxxxxxx>
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: ACPI/UEFI support for Xen/ARM status?
> 
> I've been busy with another part of this project, so I've lost track of
> progress on ACPI/UEFI support on ARM.
> 
> Last I'd read full support for ACPI/UEFI seemed a ways off.  Using a stub
> domain to constrain ACPI table parsing seemed the favored approach.  I
> was under the impression that would take some time.
> 
> What is the status?  Do the Xen/ARM leads have any guesses for when full
> ACPI/UEFI support might reach completion?

I am doing some development based on the Xen UEFI/ACPI on AArch64 using
the Arm FVP_Base platform. Using edk2 and master branch of Xen with
`CONFIG_ACPI=y`, it seems everything can work properly.

Here are some of my logs:
Shell> FS2:EFI\XEN\xen.efi
Xen 4.16-rc (c/s Fri Nov 12 02:34:01 2021 +0000 git:323b47ffd9-dirty) EFI loader
...
(XEN) PFN compression on bits 20...22
(XEN) ACPI: RSDP F5E30018, 0024 (r2 LINARO)
(XEN) ACPI: XSDT F5E3FE98, 005C (r1 LINARO RTSMVEV8        2       1000013)
(XEN) ACPI: FACP F5E3FA98, 0114 (r6 LINARO RTSMVEV8        2 LNRO        2)
(XEN) ACPI: DSDT F5E3ED98, 02AB (r2 LINARO RTSMVEV8        4 INTL 20200925)
(XEN) ACPI: GTDT F5E3FC18, 00E0 (r2 LINARO RTSMVEV8        2 LNRO        2)
(XEN) ACPI: APIC F5E3E998, 02D4 (r4 LINARO RTSMVEV8        2 LNRO        2)
(XEN) ACPI: SPCR F5E3FF98, 0050 (r2 LINARO RTSMVEV8        2 LNRO        2)
(XEN) Domain heap initialised
(XEN) Booting using ACPI
...
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd0f0]
[    0.000000] Linux version 5.14.0-rc1+ (henry@xxxx) (gcc (Ubuntu 
9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #19 SMP 
Wed Oct 13 05:18:13 EDT 2021
[    0.000000] Xen XEN_VERSION.XEN_SUBVERSION support found
[    0.000000] efi: EFI v2.50 by Xen
[    0.000000] efi: ACPI 2.0=0xf56f02a0
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x00000000F56F02A0 000024 (v02 LINARO)
[    0.000000] ACPI: XSDT 0x00000000F56F0238 000064 (v01 LINARO RTSMVEV8 
00000002      01000013)
[    0.000000] ACPI: FACP 0x00000000F56F0000 000114 (v06 LINARO RTSMVEV8 
00000002 LNRO 00000002)
[    0.000000] ACPI: DSDT 0x00000000F5E3ED98 0002AB (v02 LINARO RTSMVEV8 
00000004 INTL 20200925)
[    0.000000] ACPI: GTDT 0x00000000F5E3FC18 0000E0 (v02 LINARO RTSMVEV8 
00000002 LNRO 00000002)
[    0.000000] ACPI: APIC 0x00000000F56F0118 0000F4 (v04 LINARO RTSMVEV8 
00000002 LNRO 00000002)
[    0.000000] ACPI: SPCR 0x00000000F5E3FF98 000050 (v02 LINARO RTSMVEV8 
00000002 LNRO 00000002)
[    0.000000] ACPI: SPCR: console: pl011,mmio32,0x1c090000,115200
...

Hopefully this answers your question. :)

> 
> I noticed Linux made full ACPI/UEFI support mandatory for ARM64 before
> 3.19, so Xen's seems far behind the curve here.
> 
> While incidents of garbled ACPI tables are notorious, those are notable
> due to being rare.  Whereas I've had terrible luck with device-trees.
> The instances of any given OS *not* breaking device-trees with even
> patch-level changes are rare.
> 
> 
> --
> (\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
>  \BS (    |         ehem+sigmsg@xxxxxxx  PGP 87145445         |    )   /
>   \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
> 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0
> 8714\_|_/___/5445
> 
> 

Kind regards,

Henry