There appears to be an issue with newer QEMU versions (spotted with Arch
Linux and C9S containers) which causes the respective GH Action to hang
when booting a QEMU VM in combination with the `-cpu max` parameter.
During (a particularly painful) debugging session I once managed to get
some output from such "frozen" machine (using `earlycon` and
`earlyprintk` kernel cmdline options), and in that particular case the
VM died with a trap caused by an invalid opcode.
I couldn't reproduce this locally, only in GH Actions environment with
Arch Linux and C9S containers. Also, so far I haven't found out which
specific CPUID flag causes this, but using the `IvyBridge-v2` feature
set seems to mitigate the issue.
Add OpenSuse and Arch Linux to limited tests.
Only run the full tests against the latest stable Fedora version
to reduce the workload.
Also remove the `hung_task_panic=1` on the kernel command line, as qemu
tends to be really slow in non-kvm mode.
Frantisek Sumsal