On 05/05/2022 10.19, Mark Cave-Ayland wrote:
On 05/05/2022 02:24, Murilo Opsfelder Araújo wrote:
Hi, Mark.
On 5/4/22 11:32, Mark Cave-Ayland wrote:
On 04/05/2022 14:16, Murilo Opsfelder Araújo wrote:
Hi, Mark.
On 5/4/22 04:10, Mark Cave-Ayland wrote:
On 02/05/2022 14:36, Murilo Opsfelder Araújo wrote:
Hi, Mark.
Thanks for reviewing. Comments below.
On 5/2/22 06:43, Mark Cave-Ayland wrote:
On 30/04/2022 00:31, Murilo Opsfelder Araujo wrote:
[...]
Certainly QEMU could do better here, but then if you are already
patching the build to generate a custom configuration as above, you
might as well just patch out the relevant part of hmp-commands-info.hx
at the same time until proper per-device HMP/QMP support is added.
We are not patching the build. We are just configuring it.
That's not true though: the spec file linked above contains 20 patches to
the vanilla QEMU source, including feeding custom device lists into the
build system via
https://gitlab.com/redhat/centos-stream/rpms/qemu-kvm/-/blob/c9s/0005-Enable-disable-devices-for-RHEL.patch.
I'm sorry. I think I wasn't clear enough.
The reproducer I sent in the email was *adapted* from CentOS/RHEL
qemu-kvm.spec.
Meaning that we configured the devices in the same way that the
CentOS/RHEL package is configuring but used the unmodified QEMU source
tree from upstream.
I did that because I wanted to mimic its configuration (devices and
configure options) against the upstream code to determine if the failure
was a downstream or upstream issue.
It turns out it's an upstream regression.
Ah so that's the problem then - you can't guarantee the configuration from a
vendor-customised build will work with upstream, particularly when the build
system itself has been patched. More explanation below.
Perhaps CONFIG_MOS6522 is missing from ppc64-rh-devices?
I don't think so. Since the CONFIG_MOS6522 is available, one can build
without it and code should cope with that.
In an upstream build the default boards for each target are listed in the
configs/ directory and Kconfig specifies the dependencies such that for ppc
and ppc64 CONFIG_MOS6522 is **always** defined. However what happens in the
.spec file you linked to is that the device lists **are being overridden**
by the provided ppc64-rh-devices file which **doesn't** contain
CONFIG_MOS6522. It seems to me that the .spec file can only work with that
vendor-specific ppc64-rh-devices file if it also patches the build system to
prevent this error occurring.
Well, yes and no. QEMU was quite monolitic for many years (that's where most
of these downstream patches have their origin from), but the Kconfig stuff
that was introduced a while ago (which required quite a lot of patches to
untangle many parts of the build) was indeed meant for giving more
flexibility here, so that downstream vendors could build QEMU more easily
with only a subset of the machines (which is not only a desire by Red Hat,
by the way - do you remember the "nemu" fork a while ago for example?). We
still have quite a bit on the TODO list for full flexibility (e.g. mips
config has not been fully switched to Kconfig yet, I think), but for most
architectures, it should already work that you only select a subset of the
available machines.
However, as you already noticed the big downside is still that this is not
tested automatically in the upstream CI environment, so regressions like
this one here with the mos6522 are expected. In the long run, I think we
certainly want to test e.g. this cut-down CentOS-stream configuration in the
CI, too ... it's just a big bunch of work that nobody started to tangle with
yet.
Thomas
