After updating to the proposed kernel, I was able to boot a xenial cloud image with qemu-efi from both xenial (DTB mode) and bionic (ACPI mode).
** Attachment added: "dmesg-xenial-host.txt" https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1744754/+attachment/5084478/+files/dmesg-xenial-host.txt -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1744754 Title: qemu-efi-aarch64 in >= artful can't boot xenial cloud images Status in cloud-images: Invalid Status in edk2 package in Ubuntu: Invalid Status in linux package in Ubuntu: Fix Released Status in edk2 source package in Xenial: Invalid Status in linux source package in Xenial: Fix Committed Bug description: [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. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1744754/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
