Re: QEMU modules improvements objective (Was: Re: [RFC 0/3] Improve module accelerator error message)

From: Claudio Fontana <cfontana@suse.de>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	berrange@redhat.com, ehabkost@redhat.com,
	"Jose R. Ziviani" <jziviani@suse.de>,
	qemu-devel@nongnu.org, pbonzini@redhat.com
Subject: Re: QEMU modules improvements objective (Was: Re: [RFC 0/3] Improve module accelerator error message)
Date: Wed, 21 Jul 2021 12:47:41 +0200	[thread overview]
Message-ID: <baed353c-05da-0dcf-536b-1e7fde42275c@suse.de> (raw)
In-Reply-To: <20210721103528.5y4tvcpjggfn6hvi@sirius.home.kraxel.org>

On 7/21/21 12:35 PM, Gerd Hoffmann wrote:
>   Hi,
> 
>> Open question to all,
>>
>> why don't we have/add the ability to configure
>>
>> CONFIG_XXX=m
>>
>> for all potentially modular pieces?
>>
>> It should be possible to say, I want to build the storage plugins as modules, TCG I would like it built-in, and KVM as a module,
>> or any combination of these.
>>
>> The most useful combination I see for virtualization use of qemu is with TCG as a module (M), KVM as built-in (Y), and various other optional pieces as modules (M).
> 
> Surely doable.  Comes with maintenance and testing cost though.
> 
> For example you'll get new kinds of dependencies: when building foo as
> module stuff depending on foo must be built modular too (spice-core=m +
> qxl=y doesn't work).
> 
> I see mainly two use cases:
> 
>   (1) distro builds.  Those would enable most features and also modules
>       for fine-grained rpm/deb packaging.
> 
>   (2) builds for specific use cases.  Those would disable modules and
>       just use CONFIG_FOO=n for things they don't need.
> 
> Being able to set CONFIG_FOO=y for features used in >90% of the use
> cases (kvm, some virtio devices come to mind) might be useful for (1).
> Distros do that with linux kernel builds too (Fedora kernel has
> CONFIG_SATA_AHCI=y, CONFIG_USB_XHCI_PCI=y, ...).
> 
> But the question is: Are the benefits worth the effort?
> 
> take care,
>   Gerd
> 

I generally agree with your use cases as we see it right now from a distro perspective, I suspect there are more,
especially thinking of modeling, testing/builds etc on the TCG side of things.

I think that eventually we will end up there anyway due to the requirements being so vastly different for all possible uses of QEMU.

Doing a proper design of this will allow I think to come to the right conclusions on how to correctly check for accelerators etc,
without creating a one-off solution for each single feature.

KConfig should probably be driving this from day 1 right?

Yeah, it's tough, but I think we would otherwise just drive circles around this, implement a lot of provisional stuff,
and still end up there sooner or later in my opinion.

Ciao,

CLaudio