** Description changed:
[Impact]
After upgrading your KVM hypervisor 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]
- TBD
+ 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().
+
+ Patch 11 adds a new match method to the ARM-specific pl011 console
+ driver.
** Changed in: linux (Ubuntu Xenial)
Assignee: (unassigned) => dann frazier (dannf)
** Description changed:
[Impact]
- After upgrading your KVM hypervisor past xenial, your xenial-based guests
will fail to boot.
+ 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().
Patch 11 adds a new match method to the ARM-specific pl011 console
driver.
--
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:
New
Status in edk2 package in Ubuntu:
New
Status in linux package in Ubuntu:
Fix Released
Status in edk2 source package in Xenial:
Invalid
Status in linux source package in Xenial:
In Progress
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().
Patch 11 adds a new match method to the ARM-specific pl011 console
driver.
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
