include/qemu/module.h | 3 +++ meson.build | 3 +++ qom/object.c | 30 ++++++++++++++++++++++++++++++ util/module.c | 28 +++++++++++++++++++++------- 4 files changed, 57 insertions(+), 7 deletions(-)
Hello! I'm sending this as RFC because it's based on a patch still on review[1], so I'd like to see if it makes sense. Tt will improve the error message when an accelerator module could not be loaded. Instead of the current assert error, a formated message will be displayed. [1] https://patchwork.kernel.org/project/qemu-devel/list/?series=506379 Jose R. Ziviani (3): modules: Add CONFIG_TCG_MODULAR in config_host modules: Implement module_is_loaded function qom: Improve error message in module_object_class_by_name() include/qemu/module.h | 3 +++ meson.build | 3 +++ qom/object.c | 30 ++++++++++++++++++++++++++++++ util/module.c | 28 +++++++++++++++++++++------- 4 files changed, 57 insertions(+), 7 deletions(-) -- 2.32.0
On 7/1/21 1:27 AM, Jose R. Ziviani wrote: > Hello! > > I'm sending this as RFC because it's based on a patch still on > review[1], so I'd like to see if it makes sense. > > Tt will improve the error message when an accelerator module could > not be loaded. Instead of the current assert error, a formated > message will be displayed. > > [1] https://patchwork.kernel.org/project/qemu-devel/list/?series=506379 > > Jose R. Ziviani (3): > modules: Add CONFIG_TCG_MODULAR in config_host > modules: Implement module_is_loaded function > qom: Improve error message in module_object_class_by_name() > > include/qemu/module.h | 3 +++ > meson.build | 3 +++ > qom/object.c | 30 ++++++++++++++++++++++++++++++ > util/module.c | 28 +++++++++++++++++++++------- > 4 files changed, 57 insertions(+), 7 deletions(-) > 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). Should this not be the vision? To me it looks that way. Thanks, Claudio
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
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
On 7/21/21 12:47 PM, Claudio Fontana wrote: > 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? Before this, though, the KConfig stuff should be all-ok for ARM and possibly other archs, I am not sure where we are there.. > > 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
© 2016 - 2024 Red Hat, Inc.