Bug 2121700

Since you're using TCG + -cpu max, please be aware of
https://bugzilla.redhat.com/show_bug.cgi?id=2082806
https://gitlab.com/qemu-project/qemu/-/issues/1023
which causes intermittent crashes.  You need to use `-cpu max,la57=off'

Hmm, I think there's a strong case to be made that all the qemu-XXXX  userspace emulators should default to '-cpu max' (for targets where this exists).  We only stick with qemu64 for machine emulators, since ABI is important for VMs. There are few, if any,  guest ABI concerns for the userspace emulators, so switching to the best CPU is likely without significant downside.

I'll raise this question upstream, as it makes more sense todo that everything, rather than distro-by-distro.

Fwiw, docker is already carrying a patch to default to '-cpu max' for their userspace emulators: https://github.com/tonistiigi/binfmt/blob/master/patches/cpu-max/0001-default-to-cpu-max-on-x86-and-arm.patch
I agree it's better if this can be changed upstream.

https://lists.gnu.org/archive/html/qemu-devel/2022-08/msg04066.html(In reply to Daniel Berrangé from comment #2)

> Hmm, I think there's a strong case to be made that all the qemu-XXXX 
> userspace emulators should default to '-cpu max' (for targets where this
> exists).  We only stick with qemu64 for machine emulators, since ABI is
> important for VMs. There are few, if any,  guest ABI concerns for the
> userspace emulators, so switching to the best CPU is likely without
> significant downside.

Turns out most targets already pick the best CPU model, it was just x86 as the outlier.

(In reply to Christophe Fergeau from comment #3)
> Fwiw, docker is already carrying a patch to default to '-cpu max' for their
> userspace emulators:
> https://github.com/tonistiigi/binfmt/blob/master/patches/cpu-max/0001-
> default-to-cpu-max-on-x86-and-arm.patch
> I agree it's better if this can be changed upstream.

The arm changes there are no-ops, since 'any' gets remapped to 'max' in arm

#ifdef CONFIG_USER_ONLY
    /* For backwards compatibility usermode emulation allows "-cpu any",
     * which has the same semantics as "-cpu max".
     */
    if (!strcmp(cpunamestr, "any")) {
        cpunamestr = "max";
    }
#endif

so the only bit that really needed fixing is i386 and x86_64. I've posted

https://lists.gnu.org/archive/html/qemu-devel/2022-08/msg04066.html

(In reply to Daniel Berrangé from comment #4)
> I've posted https://lists.gnu.org/archive/html/qemu-devel/2022-08/msg04066.html

Thanks! One comment regarding the commit log (not subscribed to qemu-devel, so adding it here), 

> There's no arg to podman that can be used to change the qemu-x86_64 args, and a non-root user of podman can not change binfmt rules without elevating privileges

It's not possible to pass arguments to the binary you use through binfmt, https://www.kernel.org/doc/html/v5.19/admin-guide/binfmt-misc.html says an intermediate wrapper is needed to add arguments "If you want to pass special arguments to your interpreter, you can write a wrapper script for it". Such an intermediate wrapper is not an option for podman: when the helper is running, it is already restricted to a mount namespace (with the container filesystem) where qemu-x86_64-static won't be available.

I don't think the upstream patch was ever merged? Should this be added to the fedora packages for now?

The patches are sent for merge now, so we should be good to follow in Fedora at this point https://lists.gnu.org/archive/html/qemu-devel/2022-09/msg04787.html

Created attachment 1926383 [details]
Patch for the rawhide package

This adds the patch which went upstream to the rawhide package.

FEDORA-2023-c8a60f6f80 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-c8a60f6f80

FEDORA-2023-c8a60f6f80 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-c8a60f6f80`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-c8a60f6f80

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-c8a60f6f80 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.

Reopening as the f37 package will also need the patch. f36 works with qemu-6.2.0-17.fc36, f38 works because qemu 7.2.0 upstream has the patch. f37 still has this bug.

I created https://src.fedoraproject.org/rpms/qemu/pull-request/30 for this.

FEDORA-2023-cf93567517 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-cf93567517

FEDORA-2023-cf93567517 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-cf93567517`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-cf93567517

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2023-cf93567517 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.