Re: [PATCH 00/47] single-binary: implement dynamic filtering for QOM types

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Sep 04, 2026 at 01:25:23PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Fri, Sep 04, 2026 at 04:58:10PM +0800, Yonggang Luo wrote:
> >> Device filtering would be complicated, I guess, as there is so much
> >> CONFIG_* for devices. Another approach is to just place devices under an
> >> meson "enable_modules "  (in *.so/*.dll/*.dylib), so it won't be
> >> listed(memory consumption will also be reduced when it's not needed).
> >
> > While modules are important for reducing memory consumption, I don't think
> > they need to be a blocker - making more things into modules can be done
> > in the backaround as & when people want to work on it.
> 
> I fear modules need serious work to before we can use them more widely.
> I described issues in
> 
>     Subject: Dynamic & heterogeneous machines, initial configuration: problems
>     Date: Wed, 31 Jan 2024 21:14:21 +0100
>     Message-ID: <87o7d1i7ky.fsf@pond.sub.org>
>     https://lore.kernel.org/qemu-devel/87o7d1i7ky.fsf@pond.sub.org/
> 
> Copy of relevant part:
> 
> = Problem 3: Loadable modules =
> 
> QOM wasn't designed for loadable modules.  Support for them was grafted
> on, and there are serious deficiencies.
> 
> Building a loadable module results in a DSO.  Additionally, module
> meta-data necessary to load it is compiled into the executables that can
> load modules.  Actually loading a module can fail, e.g. when the module
> was not deployed.
> 
> Loadable modules are designed to be transparent, i.e. users don't need
> to know whether a module is compiled in or loadable.
> 
> QOM types don't exist until the module is initialized.  Compiled-in
> modules are initialized early in startup.  Loadable modules are
> initialized on load.
> 
> QMP command qom-list-types returns all QOM types.  To be able to find
> them all, it needs to load all modules.  Modules that cannot be found
> (or have dependencies that cannot be found) are silently ignored.  Any
> other loading errors are reported to stderr with error_report_err(),
> which is inappropriate.  In either case, the types provided by the
> unloadable modules are not returned by the command.
> 
> We have two functions to look up an object class by name:
> object_class_by_name() and module_object_class_by_name().  The latter
> attempts to load a module when the type doesn't exist.  Again, modules
> that cannot be found are silently ignored, and other loading errors are
> reported with error_report_err(), which is inappropriate in certain
> contexts.
> 
> When to use which of the two functions is unclear.  Existing usage may
> well be wrong.
> 
> The QOM functions to create objects in-place (object_initialize(), ...)
> or on the heap (object_new(), ...) cannot fail.  This is just fine in
> QOM's original design.  It is not fine when a loadable module fails to
> load.  Since the functions can't fail, they exit(1) then.
> 
> This means things like a hot plugging a device provided by a loadable
> module can crash a VM immediately.

The object_new() side effect is unpleasant, but we're not all that
far away from avoiding the crash on device hotplug AFAICT.

qdev_device_add_from_qdict() will call qdev_get_device_class() and
if that returns NULL will gracefully return the error to the client.

qdev_get_device_class() will call module_object_class_by_name()
which triggers module loading and can return NULL if loading
fails. Unfortnuately it throws away the error message, and
qdev_get_device_class() doesn't appear to handle NULL correctly
in all scenarios. It is not that far away from being able to
handle module load failures correctly though AFAICS.

The unpleasant bit is that we would need to audit other QMP entry
points that can trigger module loading, and ensure they all trigger
module loading prior to object_new(), and perhaps most importantly
have a way to test this in functional tests. Without the latter
we'll surely bit-rot this subtle edgecase.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|