[Impact]
After upgrading an Ubuntu/arm64 KVM host past xenial, your xenial-based guests will fail to boot.
[Test Case]
Boot a xenial cloud image with qemu-efi-aarch64 from artful/bionic.
[Regression Risk]
I've tested booting a xenial cloud image in bionic (ACPI mode), and regression tested w/ xenial's qemu-efi (DTB mode). I've regression tested on a Cavium ThunderX CRB1S, Caviumt ThunderX CRB2S and an APM X-Gene 2 Merlin board.
Patches 1-5 change only code in the GICv3 driver. The xenial GA kernel only supported 2 GICv3 systems - the 1 socket and 2 socket variants of the Cavium ThunderX CRB - and I've regression tested on those systems.
Patch 6 only adds new macro definitions.
Patch 7 is restricted to devicetree code, except for a change to earlycon.c:param_setup_earlycon(). In the case that 'earlycon' is passed on the cmdline (vs. earlycon=something), this function used to return 0 - but now it will return -ENODEV on non-devicetree systems, which is a subtle API change. However, according to kernel-parameters.txt (and the code itself), 'earlycon' by itself is only valid on devicetree systems. Just to be sure, I booted an x86 system up w/ 'earlycon' with and without this series, and observed no difference.
Patch 8 adds the SPCR table parser, but no caller to it yet. It also modifies the same earlycon code as Patch 7 - here it avoids earlycon init in the case that the devicetree-specific 'earlycon' was passed. As mentioned in my analysis Patch 7, this codepath is only supported for devicetree systems, and has been regression tested on x86.
Patch 9 turns on CONFIG_ACPI_SPCR_TABLE - however, this driver will only be built for arm64. TBH, I'm not 100% sure how Kconfig knows not to build this for other archs - but I checked the logs, and there's no spcr.o built on other archs. (Not that that should be a problem - they would just grow a bit of unused code).
Patch 10 only touches arm64-specific code, adding the call to parse_spcr(), so risk is limited to arm64.
Patch 11 adds a new match method to the ARM-specific pl011 console driver, so regression risk to other architectures is negligible.
I bisected this down to the following edk2 commit:
commit 78c41ff519b187d
Author: Ard Biesheuvel <email address hidden>
Date: Thu Mar 9 16:59:34 2017 +0100
ArmVirtPkg/
Instead of having a build time switch to prevent the FDT configuration
table from being installed, make this behavior dependent on whether we
are passing ACPI tables to the OS. This is done by looking for the
ACPI 2.0 configuration table, and only installing the FDT one if the
ACPI one cannot be found.
Which makes sense - arm64/ACPI support wasn't baked yet upstream in v4.4.