QEMU with reduced amount of machines in the config (was: [PATCH] mos6522: fix linking error when CONFIG_MOS6522 is not set)

[Thomas Huth <thuth@redhat.com>]

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