please provide newer version of edk2 that support UEFI boot of AArch64 through libvirt

[Ali]

Using current version of the qemu-efi package doesn't support UEFi boot on AArch64. Running the following hangs on wily:

qemu-system-aarch64 -enable-kvm -m 1024 -cpu host -M virt -nographic -bios QEMU_EFI.fd

Using a newer version (from May 2016) supports aarch64, but that isn't packaged for any release.

[Steve Langasek (vorlon)]

I don't know what problem you're trying to describe here, because the *only* thing the qemu-efi package does is support UEFI boot on AArch64. I'm afraid we would need more detail to understand what's going on.

It's possible that those who are running qemu-efi on arm64 systems already can provide more insight - perhaps a different qemu commandline is needed. Subscribing dann frazier who may be able to enlighten us.

[dann frazier (dannf)]

I just installed wily on a HP m400 (X-Gene) system, installed qemu-kvm and qemu-efi, and the following got me to an EFI shell:

$ sudo qemu-system-aarch64 -enable-kvm -m 1024 -cpu host -M virt -nographic -bios /usr/share/qemu-efi/QEMU_EFI.fd

Please review https://wiki.ubuntu.com/ARM64/QEMU to see if any of the documented caveats apply to your setup.

[Ali (asaidi)]

That's odd, i have a GICv2 system and the following hangs before getting to the shell:

$ qemu-system-aarch64 -enable-kvm -m 1024 -cpu host -M virt -nographic -bios /usr/share/qemu-efi/QEMU_EFI.fd
<hang, no UEFI shell>

However, this works fine. I tried
$ wget -O /usr/share/qemu-efi/QEMU_EFI-linaro.fd http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/458/QEMU-AARCH64/RELEASE_GCC49/QEMU_EFI.fd
$ qemu-system-aarch64 -enable-kvm -m 1024 -cpu host -M virt -nographic -bios /usr/share/qemu-efi/QEMU_EFI-linaro.fd
<UEFI shell>

qemu-efi 0~20150106.5 all
qemu-system-arm 1:2.3+dfsg-5

[dann frazier (dannf)]

I tested with qemu-efi 0~20150106.5c2d456b-2 and qemu-kvm 2.3+dfsg-5ubuntu9.1 - which I'm guessing is the same version as you, but your versions look to be truncated.

Can you confirm you are also running the wily kernel on the host? As mentioned on the wiki, the host kernel version can have an impact.

[Ali (asaidi)]

Sorry about the versions:
qemu-efi 0~20150106.5c2d456b-2
qemu-system-arm 1:2.3+dfsg-5ubuntu9.1

Yes, I'm running the wily kernel on the host: 4.2.0-25-generic #30-Ubuntu

I thought I tried older versions (since deleted) ran into the same behavior as with the packaged qemu-efi version, so it does seem like something going on with the EFI, but I'm not sure how to debug what is going on when the console doesn't turn-up.

[dann frazier (dannf)]

@Ali: Do you mind trying the qemu-efi from Debian/sid?

  https://packages.debian.org/source/unstable/edk2

It was updated last night - if new Linaro builds are working for you, then maybe this includes the same fix(es).

[Steve Langasek (vorlon)]

On Thu, Jan 28, 2016 at 10:34:57PM -0000, dann frazier wrote:
> @Ali: Do you mind trying the qemu-efi from Debian/sid?

> https://packages.debian.org/source/unstable/edk2

> It was updated last night - if new Linaro builds are working for you,
> then maybe this includes the same fix(es).

This version is also now available in xenial.

[Ali (asaidi)]

 0~20160104.c2a892d7-1 from both debian or xenial work for me.

Thanks guys.

FYI, libvirt doesn't approve of the path it's installed in (virt-aa-helper thinks it's a restricted path), but that is another issue.

[dann frazier (dannf)]

Fantastic!

[Ali (asaidi)]

There isn't any way to get this updated in wily, is there?

[dann frazier (dannf)]

Updates to wily would need to meet the stable release update policy:
  https://wiki.ubuntu.com/StableReleaseUpdates

Including a new upstream snapshot would not qualify. If you were able to identify a fix that meets this guidelines - e.g. a single/obviously correct changeset, then we maybe able to backport that as an SRU. If you are familiar with git bisection, that would be my recommended way to go about it. Unfortunately, since I can't reproduce the problem myself, I won't be able to assist in that process.

[Steve Langasek (vorlon)]

On Fri, Jan 29, 2016 at 09:57:40PM -0000, Ali wrote:
> There isn't any way to get this updated in wily, is there?

This would qualify as a hardware-related SRU, but unfortunately because the
version in xenial is a complete upstream update of software already in use
in wily (and other releases) that may cause regressions for other use cases,
it would be non-trivial to verify the SRU.