Arch Linux

Thanks for the suggestions, they look great to me.

I also see another namcap warning that says:
qemu-headless W: Dependency included and not needed ('xfsprogs')

The xfs support has been disabled for a while. I enabled it back with --enable-xfsctl

qemu-5.0.0-2 is in [testing]. Please check it and let me know if you see any issues.

> qemu-headless W: Dependency included and not needed ('xfsprogs')

Hmm, not so sure about this one. I just stick xfsprogs in makedepends then everyone's a winner:

xfsctl support yes

Grepping the src reveals it just wants some xfs headers (no actual lib linking) so makedepends is probably the right place. No biggie.

I believe the linking requirement comes from this function call https://github.com/qemu/qemu/blob/648db19685b7030aa558a4ddbd3a8e53d8c9a062/block/file-posix.c#L351

So I enabled this dependency.

Though I do not use XFS and don't know how important this XFS functionality is.

To be honest, I don't really use xfs either.

But it seems clear - xfsctl is enabled but linking against xfs is not needed as evidenced by namcap. Then again, maybe I place too much faith in namcap :)

Digging deeper, it appears xfsctl is some kind of system call interface to the kernel. Inside the xfs headers is simply this:

static __inline__ int xfsctl(const char *path, int fd, int cmd, void *p)
{
return ioctl(fd, cmd, p);
}

So maybe this simple function call gets inlined? Dunno.

Good point. You might be right wrt moving xfsprogs to makedeps. Let me try to do it and see how it works.

namcap also has a few more warnings and errors worth looking at:
qemu-block-rbd E: Dependency jemalloc detected and not included (libraries ['usr/lib/libjemalloc.so.2'] needed in files ['usr/lib/qemu/block-rbd.so'])
qemu-block-rbd E: Dependency ceph-libs detected and not included (libraries ['usr/lib/librbd.so.1', 'usr/lib/librados.so.2'] needed in files ['usr/lib/qemu/block-rbd.so'])
qemu-block-rbd W: Dependency included and not needed ('ceph')

BTW, I forgot to mention a bunch of other little issues (pre-existing).

1. edk blobs -> Arch now provides these in the edk2-ovmf package. There is no need at all for Arch to ship these in the qemu-arch-extra pkg. These are not compiled as part of the qemu build process and are in fact pre-compiled on some random upstream dev's workstation. They should be rm'd. Not only that, the matching JSON descriptor files need to go too.

2. Speaking of blobs -> the lists need tweaking to match upstream developments.

3. tools -> there are some new tools which don't really belong in arch-extra. Probably should be in the main qemu package.

4. Various hacks and tweaks that either go against Arch packaging guidelines or are simply unnecessary in my testing.

Suggested patch attached.


Sidenote:

> jemalloc detected

I do wonder why Arch chose to use jemalloc in qemu. I've ditched it from my personal builds after reading this:

https://lwn.net/Articles/761502/

I don't have any hard numbers but figure if it's good enough for a multi-billion $$$ company with huge resources behind the virt stack...

Not suggesting Arch do same, but it would be good for Arch devs to re-evaluate these things from time to time.

Thank you for your patch!

A question about the edk2 firmware. Are there any drawbacks for qemu users to install and use edk2-ovmf blobs? I see that edk2-ovmf filename is /usr/share/qemu/firmware/50-edk2-ovmf-i386-secure.json while one in QEMU is /usr/share/qemu/firmware/50-edk2-i386-secure.json. Do qemu users need to migrate to the new firmware blobs? Also I see that new edk2-ovmf is missing aarch64 and arm json descriptors. Is it OK?

The same question applies to *-{code,vars}.fd blobs. There are at the new location now and miss arm/aarch64 architectures.

And one more question.

> Not only that, the matching JSON descriptor files need to go too.

I see that currently these JSON descriptors are defined in QEMU sourcetree https://git.qemu.org/?p=qemu.git;a=tree;f=pc-bios/descriptors

Are you saying that we need use descriptors from somewhere else? Could you please specify what is the new source of JSON descriptors?

> A question about the edk2 firmware

My understanding about the edk2 blobs included with qemu - they are installed as a convenience for developers actually hacking on qemu itself:

https://bugzilla.redhat.com/show_bug.cgi?id=1763477#c12

If that's the case, there is no need for downstream distros to ship them. If fact, Fedora's qemu specfile rm's them because they have a separate edk2 package (compiled from source) much like Arch does now too.

As it stands currently - Arch ships the pre-compiled edk2 blobs from qemu in the "qemu-arch-extra" pkg. The corresponding JSON files are shipped in the "qemu" pkg. Confused? I certainly am :) But what I'm trying to say is - they shouldn't be shipped at all.


To be honest, I don't quite understand why Arch's new edk2-ovmf package didn't keep the same paths as the original ovmf package (which it replaced). It would have made life simpler. David did include a post_install notice about the change of paths but of course users tend to miss these notices.


About the arm blobs - yeah sorry, I failed to take them into account. But as noted above, not sure whether any Arch user would miss them. I can re-do the patch if you want to keep'em.

> Are you saying that we need use descriptors from somewhere else?

No. They need to be installed alongside the applicable firmware. The current Arch edk2-ovmf pkg does this, which is fine.

As to where do they come from? They can be produced "by hand" according to the spec, or, using the ones checked into qemu git as templates should also be fine.

> why Arch's new edk2-ovmf package didn't keep the same paths as the original ovmf package (which it replaced)

I believe it was done to match the path to the new package name (edk2-ovmf). Thus blobs were moved to /usr/share/edk2-ovmf.

BTW here is a proposed patch that adds a symlink "/usr/share/ovmf -> /usr/share/edk2-ovmf" for the backward compatibility https://bugs.archlinux.org/task/66528#comment188998

As we remove *.json files from QEMU package do we want to keep symlinks to the new location for the backward compatibility? e.g. /usr/share/qemu/firmware/50-edk2-i386-secure.json -> /usr/share/qemu/firmware/50-edk2-ovmf-i386-secure.json Or it is expected that the users update their setup to the new location right away.

> do we want to keep symlinks to the new location for the backward compatibility?

Probably not worth it IMHO.

Warning: wild speculation ahead!

For anyone to be using firmware that those descriptors pointed to, they would have had to install qemu-arch-extra. I speculate not a lot of folks install this pkg. Users of libvirt / virt-manager would likely have chosen the firmware provided by the ovmf pkg (now edk2-ovmf). If not, I'm sure we'll find out :)

I've been trying to run an aarch64 guest (https://archlinuxarm.org/platforms/armv8/generic) via virt-manager and am hitting a brick wall relating to "Failed to setup UEFI: Did not find any UEFI binary path for arch 'aarch64' Install options are limited." If I carry on, when trying to start the guest I end up with "libvirt.libvirtError: unsupported configuration: ACPI requires UEFI on this architecture".

Searching around, it looks like this needs some firmware blobs, which are apparently related to edk2-ovmf, and that eventually led me here.

Are there files missing from edk2-ovmf which are (optionally) needed by qemu-arch-extra, or is this something that qemu/virt-manager should be able to handle by itself?

> Are there files missing from edk2-ovmf which are (optionally) needed by qemu-arch-extra

Ideally you want firmware built from source. Both Fedora and Debian build the aarch64 firmware as part of their edk2 packages. Arch does not.

There are some pre-built blobs in the qemu source tarball which you could look at. I'd suggest:

1. download and unpack the qemu-5.1.0 source tarball
2. grab the file `pc-bios/descriptors/60-edk2-aarch64.json'
3. edit it to replace @DATADIR@ with a suitable path
4. grab the files `pc-bios/edk2-aarch64-code.fd.bz2' and `pc-bios/edk2-arm-vars.fd.bz2'
5. uncompress the bz2 files and place into suitable location (matching the edited json file)
6. install `60-edk2-aarch64.json' into `/usr/share/qemu/firmware'

If that works then maybe Arch could build the aarch64 firmware as part of edk2.

Righty. I've also just found `edk2-avmf` in the AUR (that repacks an RPM; I don't know how I missed that before) so I have a route to getting something working. I'll test out the QEMU blobs too.

QEMU sources have descriptors for following configurations 50-edk2-i386-secure.json 50-edk2-x86_64-secure.json 60-edk2-aarch64.json 60-edk2-arm.json 60-edk2-i386.json 60-edk2-x86_64.json

It might be indeed a good idea to include support for it in our package.

The LDFLAGS hack was added for 5.0. It is no longer useful and just makes link lines unnecessarily longer.

i.e. please delete this line from the PKGBUILD:

--extra-ldflags="$LDFLAGS"

All other issues in this bug report have now been dealt with. Please close it (once the LDFLAGS hack is removed). Thanks.

Sidenote:
When Arch upgraded to qemu-5.2.0, the call to `make' was switched to `ninja'. This goes against current upstream recommendation [1]. Luckily, it appears to be mostly harmless and results in identical binaries. Although, I've just discovered a build difference. This dir in the qemu source currently does not get compiled due to Arch calling `ninja' instead of `make':

qemu-5.2.0/pc-bios/optionrom

What actually happens now is that the precompiled roms in that dir get installed. Luckily they are bit-for-bit identical to what would otherwise be compiled. This came to light because binutils-2.36 introduced a build failure in that dir (fixed for the upcoming qemu-6.0).

In other words, it is only by pure chance that Arch avoided being bitten by this :)

[1] https://wiki.qemu.org/ChangeLog/5.2#Build_Information

Thanks, --extra-ldflags="$LDFLAGS" was removed. Closing the ticket.