Re: [PATCH v2] Loading new machines and devices from external modules

[Daniel P . Berrangé]

On Tue, Jul 19, 2022 at 04:59:22PM +0500, Drap Anton wrote:
> From: "Drap, Anton" <anton.drap@auriga.com>
> 
> There is no mechanism to load external machines and classes from modules
> at the moment. This patch is to add two parameters `add_machine` and
> `add_modinfo` for it.
> `add_machine` is to add machines from external modules.
> `add_modinfo` is to add devices from external modules, needed for a new
> machine, for example.
> Main aim is to have possibility to develop independent models and be able
> to use it with mainline QEMU. It will help to make develop new models of
> proprietary boards, simplify to use Qemu by hardware developers and extend
> number of supporting boards and devices in QEMU. It will be easier for
> small hardware manufacturers to use QEMU to develop their own board models
> and use them to shift left of FW/SW development.

IIUC, this is suggesting QEMU load pre-built .so files created from
non-upstream code, to arbitrarily extend QEMU's functionality. Such
.so files will inherantly have to be GPLd as they'll derive from
QEMU's internal APIs which are GPL. Given the proposed use case is
to emulate non-released proprietary hardware, I struggle to see how
you'll fullfill the requirements for GPL licensing of the loaded .so,
without revealing your proprietary hardware design to any who receive
the .so files.


More generally, QEMU's existing loadable module usage is explicitly
designed to try to *prevent* loading of non-upstream code. It aims
to only load code that was built as part of the integrated QEMU
build process. ie, QEMU's loadable module system is about making
it possible to build many QEMU features, but then selectively load
them at runtime to reduce footprint/attack surface. It is *not*
intended to allow non-upstream code to be loaded.


Aside from our goal to prevent/discourage GPL violation through
closed source loadable modules, QEMU also has a strong desire to
not lock ourselves into supporting a public API for loadable
modules. Maintainers wish to retain flexibility to change the
internal APIs at any time.


Partially related to this topic, there is some work taking place
with the goal of making it possible to define new machine types
in QEMU from a QAPI based JSON description.  The actual hardware
devices and CPUs would still need code to be built into QEMU
and upstream, but the way the hardware devices & CPUs are wired
together would be customizable via the JSON config.  That could
get some, but not all, of the benefits you seek without the
downsides the QEMU maintainers wish to avoid.  This isn't ready
to consume yet and we don't have any firm ETA either I'm
afraid.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|