[PATCH 0/4] modules: add support for target-specific modules.

[PATCH 0/4] modules: add support for target-specific modules.

[Gerd Hoffmann]

Based on the "modules: add metadata database" patch series sent
earlier today.  Adds support for target-specific modules to the
module code and build infrastructure.  Builds one simple module
(virtio-9p-device) for testing purposes.  Well, one module per
target to be exact ;)

Gerd Hoffmann (4):
  modules: factor out arch check
  modules: check arch on qom lookup
  modules: target-specific module build infrastructure
  modules: build virtio-9p modular

 hw/9pfs/virtio-9p-device.c |  2 ++
 util/module.c              | 30 ++++++++++++++++++++++++------
 hw/9pfs/meson.build        | 11 ++++++++++-
 meson.build                | 26 ++++++++++++++++++++++++++
 4 files changed, 62 insertions(+), 7 deletions(-)

-- 
2.31.1

[PATCH 1/4] modules: factor out arch check

[Gerd Hoffmann]

Move check to helper function for easy reuse.
No functional change.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 util/module.c | 24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/util/module.c b/util/module.c
index 4f98cc74ae37..860c257fc56e 100644
--- a/util/module.c
+++ b/util/module.c
@@ -129,6 +129,21 @@ void module_allow_arch(const char *arch)
     module_arch = arch;
 }
 
+static bool module_check_arch(ModuleInfo *info)
+{
+    if (info->has_arch) {
+        if (!module_arch) {
+            /* no arch set -> ignore all */
+            return false;
+        }
+        if (strcmp(module_arch, info->arch) != 0) {
+            /* mismatch */
+            return false;
+        }
+    }
+    return true;
+}
+
 static void module_load_path_init(void)
 {
     const char *search_dir;
@@ -301,12 +316,9 @@ bool module_load_one(const char *prefix, const char *lib_name, bool mayfail)
     module_load_modinfo();
 
     for (modlist = modinfo->list; modlist != NULL; modlist = modlist->next) {
-        if (modlist->value->has_arch) {
-            if (strcmp(modlist->value->name, module_name) == 0) {
-                if (!module_arch ||
-                    strcmp(modlist->value->arch, module_arch) != 0) {
-                    return false;
-                }
+        if (strcmp(modlist->value->name, module_name) == 0) {
+            if (!module_check_arch(modlist->value)) {
+                return false;
             }
         }
         if (modlist->value->has_deps) {
-- 
2.31.1

[PATCH 2/4] modules: check arch on qom lookup

[Gerd Hoffmann]

With target-specific modules we can have multiple modules implementing
the same object.  Therefore we have to check the target arch on lookup
to find the correct module.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 util/module.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/util/module.c b/util/module.c
index 860c257fc56e..35ba3f17cc5f 100644
--- a/util/module.c
+++ b/util/module.c
@@ -380,6 +380,9 @@ void module_load_qom_one(const char *type)
         if (!modlist->value->has_objs) {
             continue;
         }
+        if (!module_check_arch(modlist->value)) {
+            continue;
+        }
         for (sl = modlist->value->objs; sl != NULL; sl = sl->next) {
             if (strcmp(type, sl->value) == 0) {
                 module_load_one("", modlist->value->name, false);
@@ -403,6 +406,9 @@ void module_load_qom_all(void)
         if (!modlist->value->has_objs) {
             continue;
         }
+        if (!module_check_arch(modlist->value)) {
+            continue;
+        }
         module_load_one("", modlist->value->name, false);
     }
     module_loaded_qom_all = true;
-- 
2.31.1

[PATCH 3/4] modules: target-specific module build infrastructure

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 meson.build | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/meson.build b/meson.build
index 9823c5889140..a22c26850429 100644
--- a/meson.build
+++ b/meson.build
@@ -1781,6 +1781,7 @@ user_ss = ss.source_set()
 util_ss = ss.source_set()
 
 modules = {}
+target_modules = {}
 hw_arch = {}
 target_arch = {}
 target_softmmu_arch = {}
@@ -2052,6 +2053,31 @@ foreach d, list : modules
   endforeach
 endforeach
 
+foreach d, list : target_modules
+  foreach m, module_ss : list
+    if enable_modules and targetos != 'windows'
+      foreach target : target_dirs
+        config_target = config_target_mak[target]
+        config_target += config_host
+        target_inc = [include_directories('target' / config_target['TARGET_BASE_ARCH'])]
+        c_args = ['-DNEED_CPU_H',
+                  '-DCONFIG_TARGET="@0@-config-target.h"'.format(target),
+                  '-DCONFIG_DEVICES="@0@-config-devices.h"'.format(target)]
+        target_module_ss = module_ss.apply(config_target, strict: false)
+        sl = static_library(target + '-' + d + '-' + m,
+                            [genh, target_module_ss.sources()],
+                            dependencies: [modulecommon, target_module_ss.dependencies()],
+                            include_directories: target_inc,
+                            c_args: c_args,
+                            pic: true)
+        softmmu_mods += sl
+      endforeach
+    else
+      specific_ss.add_all(module_ss)
+    endif
+  endforeach
+endforeach
+
 nm = find_program('nm')
 undefsym = find_program('scripts/undefsym.py')
 block_syms = custom_target('block.syms', output: 'block.syms',
-- 
2.31.1

[PATCH 4/4] modules: build virtio-9p modular

[Gerd Hoffmann]

Simple target for testing 😊

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/9pfs/virtio-9p-device.c |  2 ++
 hw/9pfs/meson.build        | 11 ++++++++++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index 14371a78efd8..9a2df7b5126d 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -265,6 +265,8 @@ static const TypeInfo virtio_device_info = {
     .instance_size = sizeof(V9fsVirtioState),
     .class_init = virtio_9p_class_init,
 };
+module_obj(TYPE_VIRTIO_9P);
+module_arch(TARGET_NAME);
 
 static void virtio_9p_register_types(void)
 {
diff --git a/hw/9pfs/meson.build b/hw/9pfs/meson.build
index 99be5d911968..584e9432ab46 100644
--- a/hw/9pfs/meson.build
+++ b/hw/9pfs/meson.build
@@ -1,3 +1,5 @@
+hw_9pfs_modules = {}
+
 fs_ss = ss.source_set()
 fs_ss.add(files(
   '9p-local.c',
@@ -17,4 +19,11 @@ fs_ss.add(files(
 fs_ss.add(when: 'CONFIG_XEN', if_true: files('xen-9p-backend.c'))
 softmmu_ss.add_all(when: 'CONFIG_FSDEV_9P', if_true: fs_ss)
 
-specific_ss.add(when: 'CONFIG_VIRTIO_9P', if_true: files('virtio-9p-device.c'))
+if config_all_devices.has_key('CONFIG_VIRTIO_9P')
+  virtio_9p_ss = ss.source_set()
+  virtio_9p_ss.add(when: 'CONFIG_VIRTIO_9P',
+                   if_true: files('virtio-9p-device.c'))
+  hw_9pfs_modules += {'virtio-9p-device': virtio_9p_ss}
+endif
+
+target_modules += { 'hw-9pfs': hw_9pfs_modules }
-- 
2.31.1

Re: [PATCH 0/4] modules: add support for target-specific modules.

[Claudio Fontana]

On 6/10/21 12:15 PM, Gerd Hoffmann wrote:
> Based on the "modules: add metadata database" patch series sent
> earlier today.  Adds support for target-specific modules to the
> module code and build infrastructure.  Builds one simple module
> (virtio-9p-device) for testing purposes.  Well, one module per
> target to be exact ;)
> 
> Gerd Hoffmann (4):
>   modules: factor out arch check
>   modules: check arch on qom lookup
>   modules: target-specific module build infrastructure
>   modules: build virtio-9p modular
> 
>  hw/9pfs/virtio-9p-device.c |  2 ++
>  util/module.c              | 30 ++++++++++++++++++++++++------
>  hw/9pfs/meson.build        | 11 ++++++++++-
>  meson.build                | 26 ++++++++++++++++++++++++++
>  4 files changed, 62 insertions(+), 7 deletions(-)
> 

Very interesting, Cc:ing also Philippe on this.

Thanks!

CLaudio

Re: [PATCH 0/4] modules: add support for target-specific modules.

[Gerd Hoffmann]

On Thu, Jun 10, 2021 at 12:34:14PM +0200, Claudio Fontana wrote:
> On 6/10/21 12:15 PM, Gerd Hoffmann wrote:
> > Based on the "modules: add metadata database" patch series sent
> > earlier today.  Adds support for target-specific modules to the
> > module code and build infrastructure.  Builds one simple module
> > (virtio-9p-device) for testing purposes.  Well, one module per
> > target to be exact ;)
> > 
> > Gerd Hoffmann (4):
> >   modules: factor out arch check
> >   modules: check arch on qom lookup
> >   modules: target-specific module build infrastructure
> >   modules: build virtio-9p modular
> > 
> >  hw/9pfs/virtio-9p-device.c |  2 ++
> >  util/module.c              | 30 ++++++++++++++++++++++++------
> >  hw/9pfs/meson.build        | 11 ++++++++++-
> >  meson.build                | 26 ++++++++++++++++++++++++++
> >  4 files changed, 62 insertions(+), 7 deletions(-)
> > 
> 
> Very interesting, Cc:ing also Philippe on this.

Build qtest modular on top of that was easy, patch below.

I'm not convinced though that the approach will work for other
accelerators too given that they have dependencies to directories
outside accel/ ...

full branch:
  https://git.kraxel.org/cgit/qemu/log/?h=sirius/modinfo-playground

take care,
  Gerd

------------------------- cut here ----------------------
From baa7ca6bc334b043d25acd659c8d44697a2fc197 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Thu, 10 Jun 2021 13:59:25 +0200
Subject: [PATCH] modules: build qtest accel modular

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 accel/accel-common.c    | 2 +-
 accel/qtest/qtest.c     | 3 +++
 accel/meson.build       | 4 ++++
 accel/qtest/meson.build | 7 +++----
 4 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/accel/accel-common.c b/accel/accel-common.c
index cf07f78421d6..7b8ec7e0f72a 100644
--- a/accel/accel-common.c
+++ b/accel/accel-common.c
@@ -44,7 +44,7 @@ static const TypeInfo accel_type = {
 AccelClass *accel_find(const char *opt_name)
 {
     char *class_name = g_strdup_printf(ACCEL_CLASS_NAME("%s"), opt_name);
-    AccelClass *ac = ACCEL_CLASS(object_class_by_name(class_name));
+    AccelClass *ac = ACCEL_CLASS(module_object_class_by_name(class_name));
     g_free(class_name);
     return ac;
 }
diff --git a/accel/qtest/qtest.c b/accel/qtest/qtest.c
index edb29f6fa4c0..d2bca1c02151 100644
--- a/accel/qtest/qtest.c
+++ b/accel/qtest/qtest.c
@@ -45,6 +45,7 @@ static const TypeInfo qtest_accel_type = {
     .parent = TYPE_ACCEL,
     .class_init = qtest_accel_class_init,
 };
+module_obj("qtest-accel"); // FIXME: use TYPE_QTEST_ACCEL
 
 static void qtest_accel_ops_class_init(ObjectClass *oc, void *data)
 {
@@ -61,6 +62,7 @@ static const TypeInfo qtest_accel_ops_type = {
     .class_init = qtest_accel_ops_class_init,
     .abstract = true,
 };
+module_obj("qtest-accel-ops"); // FIXME: use ACCEL_OPS_NAME
 
 static void qtest_type_init(void)
 {
@@ -69,3 +71,4 @@ static void qtest_type_init(void)
 }
 
 type_init(qtest_type_init);
+module_arch(TARGET_NAME);
diff --git a/accel/meson.build b/accel/meson.build
index dfd808d2c8e5..0e824c9a3a72 100644
--- a/accel/meson.build
+++ b/accel/meson.build
@@ -1,3 +1,5 @@
+accel_modules = {}
+
 specific_ss.add(files('accel-common.c'))
 softmmu_ss.add(files('accel-softmmu.c'))
 user_ss.add(files('accel-user.c'))
@@ -16,3 +18,5 @@ dummy_ss.add(files(
 
 specific_ss.add_all(when: ['CONFIG_SOFTMMU', 'CONFIG_POSIX'], if_true: dummy_ss)
 specific_ss.add_all(when: ['CONFIG_XEN'], if_true: dummy_ss)
+
+target_modules += { 'accel' : accel_modules }
diff --git a/accel/qtest/meson.build b/accel/qtest/meson.build
index a2f327645980..d106bb33c36a 100644
--- a/accel/qtest/meson.build
+++ b/accel/qtest/meson.build
@@ -1,6 +1,5 @@
 qtest_ss = ss.source_set()
-qtest_ss.add(files(
-  'qtest.c',
-))
+qtest_ss.add(when: ['CONFIG_SOFTMMU', 'CONFIG_POSIX'],
+             if_true: files('qtest.c'))
 
-specific_ss.add_all(when: ['CONFIG_SOFTMMU', 'CONFIG_POSIX'], if_true: qtest_ss)
+accel_modules += {'qtest': qtest_ss }
-- 
2.31.1

Re: [PATCH 0/4] modules: add support for target-specific modules.

[Gerd Hoffmann]

  Hi,

> Build qtest modular on top of that was easy, patch below.
> 
> I'm not convinced though that the approach will work for other
> accelerators too given that they have dependencies to directories
> outside accel/ ...

Oh, it depends on how high you hang the tcg modularization bar.

Building only the tcg accel ops as module is easy too, but that
of course leaves a large chunk of tcg linked into qemu itself.

take care,
  Gerd

From 8062aabd26f12bd8199b43c631a3aba8f195183e Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Thu, 10 Jun 2021 14:48:20 +0200
Subject: [PATCH] modules: build tcg accel modular
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

It's not all of tcg, only the accel ops, but its a start 😊

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 accel/accel-softmmu.c     | 2 +-
 accel/tcg/tcg-accel-ops.c | 2 ++
 accel/tcg/meson.build     | 6 ++++++
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/accel/accel-softmmu.c b/accel/accel-softmmu.c
index 50fa5acaa401..67276e4f5222 100644
--- a/accel/accel-softmmu.c
+++ b/accel/accel-softmmu.c
@@ -72,7 +72,7 @@ void accel_init_ops_interfaces(AccelClass *ac)
     g_assert(ac_name != NULL);
 
     ops_name = g_strdup_printf("%s" ACCEL_OPS_SUFFIX, ac_name);
-    ops = ACCEL_OPS_CLASS(object_class_by_name(ops_name));
+    ops = ACCEL_OPS_CLASS(module_object_class_by_name(ops_name));
     g_free(ops_name);
 
     /*
diff --git a/accel/tcg/tcg-accel-ops.c b/accel/tcg/tcg-accel-ops.c
index 7191315aeed4..432a76d2ea29 100644
--- a/accel/tcg/tcg-accel-ops.c
+++ b/accel/tcg/tcg-accel-ops.c
@@ -124,9 +124,11 @@ static const TypeInfo tcg_accel_ops_type = {
     .class_init = tcg_accel_ops_class_init,
     .abstract = true,
 };
+module_obj("tcg-accel-ops"); // FIXME: use ACCEL_OPS_NAME
 
 static void tcg_accel_ops_register_types(void)
 {
     type_register_static(&tcg_accel_ops_type);
 }
 type_init(tcg_accel_ops_register_types);
+module_arch(TARGET_NAME);
diff --git a/accel/tcg/meson.build b/accel/tcg/meson.build
index 1236ac7b910b..0362b1bd5918 100644
--- a/accel/tcg/meson.build
+++ b/accel/tcg/meson.build
@@ -15,8 +15,14 @@ specific_ss.add_all(when: 'CONFIG_TCG', if_true: tcg_ss)
 
 specific_ss.add(when: ['CONFIG_SOFTMMU', 'CONFIG_TCG'], if_true: files(
   'cputlb.c',
+))
+
+tcg_module_ss = ss.source_set()
+tcg_module_ss.add(when: ['CONFIG_SOFTMMU', 'CONFIG_TCG'], if_true: files(
   'tcg-accel-ops.c',
   'tcg-accel-ops-mttcg.c',
   'tcg-accel-ops-icount.c',
   'tcg-accel-ops-rr.c'
 ))
+
+accel_modules += {'tcg': tcg_module_ss }
-- 
2.31.1

Re: [PATCH 0/4] modules: add support for target-specific modules.

[Claudio Fontana]

On 6/10/21 2:23 PM, Gerd Hoffmann wrote:
> On Thu, Jun 10, 2021 at 12:34:14PM +0200, Claudio Fontana wrote:
>> On 6/10/21 12:15 PM, Gerd Hoffmann wrote:
>>> Based on the "modules: add metadata database" patch series sent
>>> earlier today.  Adds support for target-specific modules to the
>>> module code and build infrastructure.  Builds one simple module
>>> (virtio-9p-device) for testing purposes.  Well, one module per
>>> target to be exact ;)
>>>
>>> Gerd Hoffmann (4):
>>>   modules: factor out arch check
>>>   modules: check arch on qom lookup
>>>   modules: target-specific module build infrastructure
>>>   modules: build virtio-9p modular
>>>
>>>  hw/9pfs/virtio-9p-device.c |  2 ++
>>>  util/module.c              | 30 ++++++++++++++++++++++++------
>>>  hw/9pfs/meson.build        | 11 ++++++++++-
>>>  meson.build                | 26 ++++++++++++++++++++++++++
>>>  4 files changed, 62 insertions(+), 7 deletions(-)
>>>
>>
>> Very interesting, Cc:ing also Philippe on this.
> 
> Build qtest modular on top of that was easy, patch below.
> 
> I'm not convinced though that the approach will work for other
> accelerators too given that they have dependencies to directories
> outside accel/ ...


The difficulty is that accelerator code is going to be split across a large number of directories.
This was the biggest problem with the previous Makefile based module support.

Whatever the solution we cook, we need to consider this, it is not going to be just a single file or a bunch of files in a directory.

See this obsolete draft patch of mine just for illustrative purposes (does not apply, should not be applied).


From: Claudio Fontana <cfontana@suse.de>
Date: Sun, 10 May 2020 13:31:11 +0200
Subject: [PATCH 2/2] Makefile.target: add per-target tcg module

Signed-off-by: Claudio Fontana <cfontana@suse.de>
---
 Makefile.target                            | 22 ++++++++++++++++------
 accel/Makefile.objs                        |  2 +-
 accel/tcg/Makefile.objs                    | 16 +++++++---------
 configure                                  |  2 +-
 disas/{tci.c => accel-tcg-tci.c}           |  0
 fpu/{softfloat.c => accel-tcg-softfloat.c} |  0
 rules.mak                                  | 14 ++++++++++----
 target/i386/Makefile.objs                  | 12 +++++++-----
 tcg/Makefile.objs                          |  4 ++++
 9 files changed, 46 insertions(+), 26 deletions(-)
 rename disas/{tci.c => accel-tcg-tci.c} (100%)
 rename fpu/{softfloat.c => accel-tcg-softfloat.c} (100%)
 create mode 100644 tcg/Makefile.objs

diff --git a/Makefile.target b/Makefile.target
index 4cf4af504b..c0e8f298fc 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -109,12 +109,22 @@ obj-y += trace/
 # cpu emulator library
 obj-y += exec.o exec-vary.o
 obj-y += accel/
-obj-$(CONFIG_TCG) += tcg/tcg.o tcg/tcg-op.o tcg/tcg-op-vec.o tcg/tcg-op-gvec.o
-obj-$(CONFIG_TCG) += tcg/tcg-common.o tcg/optimize.o
-obj-$(CONFIG_TCG_INTERPRETER) += tcg/tci.o
-obj-$(CONFIG_TCG_INTERPRETER) += disas/tci.o
-obj-$(CONFIG_TCG) += fpu/softfloat.o
 obj-y += target/$(TARGET_BASE_ARCH)/
+
+accel-obj-$(CONFIG_TCG) += accel/
+accel-obj-$(CONFIG_TCG) += tcg/
+accel-obj-$(CONFIG_TCG) += fpu/accel-tcg-softfloat.o
+accel-obj-$(CONFIG_TCG) += target/$(TARGET_BASE_ARCH)/
+accel-obj-$(CONFIG_TCG) += $(if $(CONFIG_TCI_INTERPRETER),disas/accel-tcg-tci.o)
+
+ifeq ($(CONFIG_MODULES)$(CONFIG_TCG),ym)
+accel-tcg-modules := accel/tcg/accel-tcg.mo tcg/accel-tcg-lib.mo fpu/accel-tcg-softfloat.mo
+accel-tcg-modules += target/$(TARGET_BASE_ARCH)/accel-tcg-target.mo
+accel-tcg-modules += $(if $(CONFIG_TCI_INTERPRETER),disas/accel-tcg-tci.mo)
+accel-tcg$(DSOSUF): $(accel-tcg-modules)
+	$(call LINKDEP "$^")
+endif
+
 obj-y += disas.o
 obj-$(call notempty,$(TARGET_XML_FILES)) += gdbstub-xml.o
 LIBS := $(libs_cpu) $(LIBS)
@@ -208,7 +218,7 @@ endif
 COMMON_LDADDS = ../libqemuutil.a
 
 # build either PROG or PROGW
-$(QEMU_PROG_BUILD): $(all-obj-y) $(COMMON_LDADDS) $(softmmu-main-y)
+$(QEMU_PROG_BUILD): $(all-obj-y) $(COMMON_LDADDS) $(softmmu-main-y) $(if $(and $(CONFIG_MODULES),$(findstring m,$(CONFIG_TCG))),accel-tcg$(DSOSUF))
 	$(call LINK, $(filter-out %.mak, $^))
 ifdef CONFIG_DARWIN
 	$(call quiet-command,Rez -append $(SRC_PATH)/pc-bios/qemu.rsrc -o $@,"REZ","$(TARGET_DIR)$@")
diff --git a/accel/Makefile.objs b/accel/Makefile.objs
index 17e5ac6061..f4c696d4a5 100644
--- a/accel/Makefile.objs
+++ b/accel/Makefile.objs
@@ -1,5 +1,5 @@
 common-obj-$(CONFIG_SOFTMMU) += accel.o
 obj-$(call land,$(CONFIG_SOFTMMU),$(CONFIG_POSIX)) += qtest.o
 obj-$(CONFIG_KVM) += kvm/
-obj-$(CONFIG_TCG) += tcg/
+accel-obj-$(CONFIG_TCG) += tcg/
 obj-y += stubs/
diff --git a/accel/tcg/Makefile.objs b/accel/tcg/Makefile.objs
index a92f2c454b..be52189613 100644
--- a/accel/tcg/Makefile.objs
+++ b/accel/tcg/Makefile.objs
@@ -1,9 +1,7 @@
-obj-$(CONFIG_SOFTMMU) += tcg-all.o
-obj-$(CONFIG_SOFTMMU) += cputlb.o
-obj-y += tcg-runtime.o tcg-runtime-gvec.o
-obj-y += cpu-exec.o cpu-exec-common.o translate-all.o
-obj-y += translator.o
-
-obj-$(CONFIG_USER_ONLY) += user-exec.o
-obj-$(call lnot,$(CONFIG_SOFTMMU)) += user-exec-stub.o
-obj-$(CONFIG_PLUGIN) += plugin-gen.o
+accel-obj-$(CONFIG_TCG) += accel-tcg.mo
+accel-tcg.mo-objs += $(if $(CONFIG_SOFTMMU),tcg-all.o cputlb.o,user-exec-stub.o)
+accel-tcg.mo-objs += $(if $(CONFIG_USER_ONLY),user-exec.o,)
+accel-tcg.mo-objs += $(if $(CONFIG_PLUGIN),plugin-gen.o,)
+accel-tcg.mo-objs += tcg-runtime.o tcg-runtime-gvec.o
+accel-tcg.mo-objs += cpu-exec.o cpu-exec-common.o translate-all.o
+accel-tcg.mo-objs += translator.o
diff --git a/configure b/configure
index 0d69c360c0..42d1b5c30c 100755
--- a/configure
+++ b/configure
@@ -7207,7 +7207,7 @@ if test "$optreset" = "yes" ; then
   echo "HAVE_OPTRESET=y" >> $config_host_mak
 fi
 if test "$tcg" = "yes"; then
-  echo "CONFIG_TCG=y" >> $config_host_mak
+  echo "CONFIG_TCG=m" >> $config_host_mak
   if test "$tcg_interpreter" = "yes" ; then
     echo "CONFIG_TCG_INTERPRETER=y" >> $config_host_mak
   fi
diff --git a/disas/tci.c b/disas/accel-tcg-tci.c
similarity index 100%
rename from disas/tci.c
rename to disas/accel-tcg-tci.c
diff --git a/fpu/softfloat.c b/fpu/accel-tcg-softfloat.c
similarity index 100%
rename from fpu/softfloat.c
rename to fpu/accel-tcg-softfloat.c
diff --git a/rules.mak b/rules.mak
index 694865b63e..e93faa6e47 100644
--- a/rules.mak
+++ b/rules.mak
@@ -80,6 +80,11 @@ LINK = $(call quiet-command, $(LINKPROG) $(CFLAGS) $(QEMU_LDFLAGS) -o $@ \
        $(call process-archive-undefs, $1) \
        $(version-obj-y) $(call extract-libs,$1) $(LIBS),"LINK","$(TARGET_DIR)$@")
 
+# simple link using the passed deps instead of LIBS used to build a DSO
+# from multiple .mo files
+LINKDEP = $(call quiet-command, $(LINKPROG) $(CFLAGS) $(QEMU_LDFLAGS) -o $@ \
+       $(version-obj-y) $^,"LINK","$(TARGET_DIR)$@")
+
 %.o: %.S
 	$(call quiet-command,$(CCAS) $(QEMU_LOCAL_INCLUDES) $(QEMU_INCLUDES) \
 	       $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) \
@@ -106,11 +111,12 @@ LINK = $(call quiet-command, $(LINKPROG) $(CFLAGS) $(QEMU_LDFLAGS) -o $@ \
 DSO_OBJ_CFLAGS := -fPIC -DBUILD_DSO
 module-common.o: CFLAGS += $(DSO_OBJ_CFLAGS)
 %$(DSOSUF): QEMU_LDFLAGS += $(LDFLAGS_SHARED)
-%$(DSOSUF): %.mo
+../%$(DSOSUF): DEST=$(subst /,-,$(subst ../,,$@))
+../%$(DSOSUF): ../%.mo
+	@# Link non-accelerator, non-target-specific modules
 	$(call LINK,$^)
 	@# Copy to build root so modules can be loaded when program started without install
-	$(if $(findstring /,$@),$(call quiet-command,cp $@ $(subst /,-,$@),"CP","$(subst /,-,$@)"))
-
+	$(call quiet-command,cp $@ ../$(DEST),"CP","$(DEST)")
 
 LD_REL := $(CC) -nostdlib $(LD_REL_FLAGS)
 
@@ -364,7 +370,7 @@ define unnest-vars
                    $(eval $($o-objs): CFLAGS += $(DSO_OBJ_CFLAGS))
                    $(eval $o: $($o-objs)))
              $(eval $(patsubst %-m,%-y,$v) += $($v))
-             $(eval modules: $($v:%.mo=%$(DSOSUF))),
+             $(if $(findstring accel-,$(v)),,$(eval modules: $($v:%.mo=%$(DSOSUF)))),
              $(eval $(patsubst %-m,%-y,$v) += $(call expand-objs, $($v)))))
 
     # Post-process all the unnested vars
diff --git a/target/i386/Makefile.objs b/target/i386/Makefile.objs
index 186c6091ce..5f3e83c66d 100644
--- a/target/i386/Makefile.objs
+++ b/target/i386/Makefile.objs
@@ -1,9 +1,11 @@
 obj-y += helper.o cpu.o gdbstub.o xsave_helper.o cpu-dump.o xcc-hw.o
-obj-$(CONFIG_TCG) += translate.o
-obj-$(CONFIG_TCG) += bpt_helper.o cc_helper.o excp_helper.o fpu_helper.o
-obj-$(CONFIG_TCG) += int_helper.o mem_helper.o misc_helper.o mpx_helper.o
-obj-$(CONFIG_TCG) += seg_helper.o smm_helper.o svm_helper.o
-obj-$(CONFIG_TCG) += helper-tcg.o xcc-tcg.o






> 
> full branch:
>   https://git.kraxel.org/cgit/qemu/log/?h=sirius/modinfo-playground
> 
> take care,
>   Gerd
> 
> ------------------------- cut here ----------------------
> From baa7ca6bc334b043d25acd659c8d44697a2fc197 Mon Sep 17 00:00:00 2001
> From: Gerd Hoffmann <kraxel@redhat.com>
> Date: Thu, 10 Jun 2021 13:59:25 +0200
> Subject: [PATCH] modules: build qtest accel modular
> 
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  accel/accel-common.c    | 2 +-
>  accel/qtest/qtest.c     | 3 +++
>  accel/meson.build       | 4 ++++
>  accel/qtest/meson.build | 7 +++----
>  4 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/accel/accel-common.c b/accel/accel-common.c
> index cf07f78421d6..7b8ec7e0f72a 100644
> --- a/accel/accel-common.c
> +++ b/accel/accel-common.c
> @@ -44,7 +44,7 @@ static const TypeInfo accel_type = {
>  AccelClass *accel_find(const char *opt_name)
>  {
>      char *class_name = g_strdup_printf(ACCEL_CLASS_NAME("%s"), opt_name);
> -    AccelClass *ac = ACCEL_CLASS(object_class_by_name(class_name));
> +    AccelClass *ac = ACCEL_CLASS(module_object_class_by_name(class_name));
>      g_free(class_name);
>      return ac;
>  }
> diff --git a/accel/qtest/qtest.c b/accel/qtest/qtest.c
> index edb29f6fa4c0..d2bca1c02151 100644
> --- a/accel/qtest/qtest.c
> +++ b/accel/qtest/qtest.c
> @@ -45,6 +45,7 @@ static const TypeInfo qtest_accel_type = {
>      .parent = TYPE_ACCEL,
>      .class_init = qtest_accel_class_init,
>  };
> +module_obj("qtest-accel"); // FIXME: use TYPE_QTEST_ACCEL
>  
>  static void qtest_accel_ops_class_init(ObjectClass *oc, void *data)
>  {
> @@ -61,6 +62,7 @@ static const TypeInfo qtest_accel_ops_type = {
>      .class_init = qtest_accel_ops_class_init,
>      .abstract = true,
>  };
> +module_obj("qtest-accel-ops"); // FIXME: use ACCEL_OPS_NAME
>  
>  static void qtest_type_init(void)
>  {
> @@ -69,3 +71,4 @@ static void qtest_type_init(void)
>  }
>  
>  type_init(qtest_type_init);
> +module_arch(TARGET_NAME);
> diff --git a/accel/meson.build b/accel/meson.build
> index dfd808d2c8e5..0e824c9a3a72 100644
> --- a/accel/meson.build
> +++ b/accel/meson.build
> @@ -1,3 +1,5 @@
> +accel_modules = {}
> +
>  specific_ss.add(files('accel-common.c'))
>  softmmu_ss.add(files('accel-softmmu.c'))
>  user_ss.add(files('accel-user.c'))
> @@ -16,3 +18,5 @@ dummy_ss.add(files(
>  
>  specific_ss.add_all(when: ['CONFIG_SOFTMMU', 'CONFIG_POSIX'], if_true: dummy_ss)
>  specific_ss.add_all(when: ['CONFIG_XEN'], if_true: dummy_ss)
> +
> +target_modules += { 'accel' : accel_modules }
> diff --git a/accel/qtest/meson.build b/accel/qtest/meson.build
> index a2f327645980..d106bb33c36a 100644
> --- a/accel/qtest/meson.build
> +++ b/accel/qtest/meson.build
> @@ -1,6 +1,5 @@
>  qtest_ss = ss.source_set()
> -qtest_ss.add(files(
> -  'qtest.c',
> -))
> +qtest_ss.add(when: ['CONFIG_SOFTMMU', 'CONFIG_POSIX'],
> +             if_true: files('qtest.c'))
>  
> -specific_ss.add_all(when: ['CONFIG_SOFTMMU', 'CONFIG_POSIX'], if_true: qtest_ss)
> +accel_modules += {'qtest': qtest_ss }
> 

Re: [PATCH 0/4] modules: add support for target-specific modules.

[Paolo Bonzini]

On 10/06/21 15:12, Claudio Fontana wrote:
> The difficulty is that accelerator code is going to be split across a
> large number of directories.

It should be possible to use a sourceset per target; just like there is
target_arch, target_softmmu_arch, target_user_arch we can add
target_softmmu_accel_arch['i386']['tcg'].

So each module would include both accel_modules[accel] and 
target_softmmu_accel_arch[arch][accel].

Another possibility is to use a single-level of dictionaries, e.g. 
target_softmmu_accel_arch['i386'], and select files using CONFIG_* 
symbols.  That would be a bit neater but harder to implement.  It can be 
done later.

Paolo

Re: [PATCH 0/4] modules: add support for target-specific modules.

[Gerd Hoffmann]

On Fri, Jun 11, 2021 at 09:35:42AM +0200, Paolo Bonzini wrote:
> On 10/06/21 15:12, Claudio Fontana wrote:
> > The difficulty is that accelerator code is going to be split across a
> > large number of directories.

We basically have to define the source sets at the toplevel meson.build
file, then go fill the source sets in the subdir meson.build files.

The extra indirection needed in the Makefiles (build one temporary
module per subdirectory, then go link them into the final module) is not
needed with meson.

> It should be possible to use a sourceset per target; just like there is
> target_arch, target_softmmu_arch, target_user_arch we can add
> target_softmmu_accel_arch['i386']['tcg'].

I think you can even use a single source set, then go use 

	tcg_module_ss.add(when: 'TARGET_I386', ...)

for arch-specific stuff like the files in target/i386/tcg/


Are there any pending patches to handle the remaining tcg dependencies
in qemu?  When trying to build tcg modular (more than only
tcg-accel-ops*) I get lots of unresolved symbols to tcg bits which are
referenced directly (in cpu.c, gdbstub.c, monitor, ...).

The CONFIG_TCG=n case is handled either with stubs or with #ifdef
CONFIG_TCG, which doesn't fly for modular tcg ...

take care,
  Gerd

Re: [PATCH 0/4] modules: add support for target-specific modules.

[Gerd Hoffmann]

  Hi,

> Are there any pending patches to handle the remaining tcg dependencies
> in qemu?  When trying to build tcg modular (more than only
> tcg-accel-ops*) I get lots of unresolved symbols to tcg bits which are
> referenced directly (in cpu.c, gdbstub.c, monitor, ...).
> 
> The CONFIG_TCG=n case is handled either with stubs or with #ifdef
> CONFIG_TCG, which doesn't fly for modular tcg ...

So, enough for today, to be continued next week.
Work branch pushed to
    https://git.kraxel.org/cgit/qemu/log/?h=sirius/modinfo-playground

Topmost patch doesn't compile but shows the build changes.

take care,
  Gerd

Re: [PATCH 0/4] modules: add support for target-specific modules.

[Claudio Fontana]

On 6/11/21 3:03 PM, Gerd Hoffmann wrote:
>   Hi,
> 
>> Are there any pending patches to handle the remaining tcg dependencies
>> in qemu?  When trying to build tcg modular (more than only
>> tcg-accel-ops*) I get lots of unresolved symbols to tcg bits which are
>> referenced directly (in cpu.c, gdbstub.c, monitor, ...).
>>
>> The CONFIG_TCG=n case is handled either with stubs or with #ifdef
>> CONFIG_TCG, which doesn't fly for modular tcg ...


We need CONFIG_TCG=m right?

Which means quite a few changes.

> 
> So, enough for today, to be continued next week.
> Work branch pushed to
>     https://git.kraxel.org/cgit/qemu/log/?h=sirius/modinfo-playground
> 
> Topmost patch doesn't compile but shows the build changes.
> 
> take care,
>   Gerd
> 

Re: [PATCH 0/4] modules: add support for target-specific modules.

[Paolo Bonzini]

On 11/06/21 10:29, Gerd Hoffmann wrote:
> 
> Are there any pending patches to handle the remaining tcg dependencies
> in qemu?  When trying to build tcg modular (more than only
> tcg-accel-ops*) I get lots of unresolved symbols to tcg bits which are
> referenced directly (in cpu.c, gdbstub.c, monitor, ...).

I suggest that you create a wiki page with a list.  Then we can either 
see if Claudio's makefile patches tackled them, or go through them one 
by one.

Paolo

Re: [PATCH 0/4] modules: add support for target-specific modules.

[José Ricardo Ziviani]

[-- Attachment #1.1: Type: text/plain, Size: 2055 bytes --]

Hello Gerd,

On sexta-feira, 11 de junho de 2021 10:03:21 -03 Gerd Hoffmann wrote:
>   Hi,
> 
> > Are there any pending patches to handle the remaining tcg dependencies
> > in qemu?  When trying to build tcg modular (more than only
> > tcg-accel-ops*) I get lots of unresolved symbols to tcg bits which are
> > referenced directly (in cpu.c, gdbstub.c, monitor, ...).
> > 
> > The CONFIG_TCG=n case is handled either with stubs or with #ifdef
> > CONFIG_TCG, which doesn't fly for modular tcg ...
> 
> So, enough for today, to be continued next week.
> Work branch pushed to
>     https://git.kraxel.org/cgit/qemu/log/?h=sirius/modinfo-playground
> 
> Topmost patch doesn't compile but shows the build changes.

I cloned your 'sirius/modinfo-playground-good' and started playing with the 
command line options to build these modules. I would like to suggest to change 
the current "--enable-X" with "--X=[enabled,disabled,module]", that seems to 
make more sense for these modules. For instance:

$ ../configure --target-list=x86_64-softmmu --tcg=module
...
Targets and accelerators
              ...
              TCG support: YES
              TCG backend: module (x86_64)
        TCG debug enabled: NO
              target list: x86_64-softmmu
              ...

$ ../configure --target-list=x86_64-softmmu --tcg=disabled
...
Targets and accelerators
              ...
              TCG support: NO
              target list: x86_64-softmmu
              ...

$ ../configure --target-list=x86_64-softmmu --tcg=enabled # (default)
...
Targets and accelerators
              ...
              TCG support: YES
              TCG backend: native (x86_64)
        TCG debug enabled: NO
              target list: x86_64-softmmu
              ...

I attached a small patch here, just to illustrate what I'm saying. If you like 
the suggestion I can start implementing it for those modules you're currently 
working on. What do you think?

Thank you,

José R. Ziviani

> 
> take care,
>   Gerd


[-- Attachment #1.2: 0001-Add-tcg-option-to-the-build-system.patch --]
[-- Type: text/x-patch, Size: 9103 bytes --]

From 8e4cc80aae337ab8064f3ab55d3e5916186a0b19 Mon Sep 17 00:00:00 2001
From: "Jose R. Ziviani" <jziviani@suse.de>
Date: Mon, 14 Jun 2021 18:56:49 -0300
Subject: [PATCH] Add --tcg option to the build system

---
 configure            |  8 ++++++--
 meson.build          | 36 +++++++++++++++++++++++-------------
 meson_options.txt    |  3 ++-
 scripts/minikconf.py | 22 ++++++++++++++--------
 tests/meson.build    |  2 +-
 5 files changed, 46 insertions(+), 25 deletions(-)

diff --git a/configure b/configure
index 8dcb9965b2..95ed0c25c1 100755
--- a/configure
+++ b/configure
@@ -1105,7 +1105,7 @@ for opt do
   ;;
   --disable-tcg) tcg="disabled"
   ;;
-  --enable-tcg) tcg="enabled"
+  --tcg=*) tcg="$optarg"
   ;;
   --disable-malloc-trim) malloc_trim="disabled"
   ;;
@@ -1792,6 +1792,7 @@ Advanced options (experts only):
                            Default:trace-<pid>
   --disable-slirp          disable SLIRP userspace network connectivity
   --enable-tcg-interpreter enable TCI (TCG with bytecode interpreter, experimental and slow)
+  --tcg=OPTION             configure TCG accelerator [enabled|disabled|module]
   --enable-malloc-trim     enable libc malloc_trim() for memory optimization
   --oss-lib                path to OSS library
   --cpu=CPU                Build for host CPU [$cpu]
@@ -2288,7 +2289,10 @@ if test "$solaris" = "yes" ; then
   fi
 fi
 
-if test "$tcg" = "enabled"; then
+if test "$tcg" = "disabled"; then
+    debug_tcg="no"
+    tcg_interpreter="false"
+else
     git_submodules="$git_submodules tests/fp/berkeley-testfloat-3"
     git_submodules="$git_submodules tests/fp/berkeley-softfloat-3"
 fi
diff --git a/meson.build b/meson.build
index 46ebc07dbb..c372f6363e 100644
--- a/meson.build
+++ b/meson.build
@@ -195,7 +195,7 @@ elif targetos == 'haiku'
             cc.find_library('network'),
             cc.find_library('bsd')]
 elif targetos == 'openbsd'
-  if not get_option('tcg').disabled() and target_dirs.length() > 0
+  if get_option('tcg') != 'disabled' and target_dirs.length() > 0
     # Disable OpenBSD W^X if available
     emulator_link_args = cc.get_supported_link_arguments('-Wl,-z,wxneeded')
   endif
@@ -241,7 +241,7 @@ if targetos == 'netbsd'
 endif
 
 tcg_arch = config_host['ARCH']
-if not get_option('tcg').disabled()
+if get_option('tcg') != 'disabled'
   if cpu not in supported_cpus
     if get_option('tcg_interpreter')
       warning('Unsupported CPU @0@, will use TCG with TCI (experimental and slow)'.format(cpu))
@@ -273,7 +273,11 @@ if not get_option('tcg').disabled()
                         language: ['c', 'cpp', 'objc'])
 
   accelerators += 'CONFIG_TCG'
-  config_host += { 'CONFIG_TCG': 'y' }
+  if get_option('tcg') == 'module'
+    config_host += { 'CONFIG_TCG': 'm' }
+  else
+    config_host += { 'CONFIG_TCG': 'y' }
+  endif
 endif
 
 if 'CONFIG_KVM' not in accelerators and get_option('kvm').enabled()
@@ -1306,19 +1310,20 @@ foreach target : target_dirs
   accel_kconfig = []
   foreach sym: accelerators
     if sym == 'CONFIG_TCG' or target in accelerator_targets.get(sym, [])
-      config_target += { sym: 'y' }
-      config_all += { sym: 'y' }
+      if sym == 'CONFIG_TCG' and get_option('tcg') == 'module'
+        config_target += { sym: 'm' }
+        config_all += { sym: 'm' }
+        accel_kconfig += [ sym + '=m' ]
+      else
+        config_target += { sym: 'y' }
+        config_all += { sym: 'y' }
+        accel_kconfig += [ sym + '=y' ]
+      endif
       if sym == 'CONFIG_TCG' and tcg_arch == 'tci'
         config_target += { 'CONFIG_TCG_INTERPRETER': 'y' }
       elif sym == 'CONFIG_XEN' and have_xen_pci_passthrough
         config_target += { 'CONFIG_XEN_PCI_PASSTHROUGH': 'y' }
       endif
-      if target in modular_tcg
-        config_target += { 'CONFIG_TCG_MODULAR': 'y' }
-      else
-        config_target += { 'CONFIG_TCG_BUILTIN': 'y' }
-      endif
-      accel_kconfig += [ sym + '=y' ]
     endif
   endforeach
   if accel_kconfig.length() == 0
@@ -2039,8 +2044,11 @@ subdir('tests/qtest/fuzz')
 
 # accel modules
 tcg_real_module_ss = ss.source_set()
-tcg_real_module_ss.add_all(when: 'CONFIG_TCG_MODULAR', if_true: tcg_module_ss)
-specific_ss.add_all(when: 'CONFIG_TCG_BUILTIN', if_true: tcg_module_ss)
+if get_option('tcg') == 'module'
+  tcg_real_module_ss.add_all(when: 'CONFIG_TCG_MODULAR', if_true: tcg_module_ss)
+else
+  specific_ss.add_all(when: 'CONFIG_TCG_BUILTIN', if_true: tcg_module_ss)
+endif
 target_modules += { 'accel' : { 'qtest': qtest_module_ss,
                                 'tcg': tcg_real_module_ss }}
 
@@ -2689,6 +2697,8 @@ summary_info += {'TCG support':       config_all.has_key('CONFIG_TCG')}
 if config_all.has_key('CONFIG_TCG')
   if get_option('tcg_interpreter')
     summary_info += {'TCG backend':   'TCI (TCG with bytecode interpreter, experimental and slow)'}
+  elif get_option('tcg') == 'module'
+    summary_info += {'TCG backend':   'module (@0@)'.format(cpu)}
   else
     summary_info += {'TCG backend':   'native (@0@)'.format(cpu)}
   endif
diff --git a/meson_options.txt b/meson_options.txt
index 3d304cac96..332dacd8ec 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -39,7 +39,8 @@ option('xen', type: 'feature', value: 'auto',
        description: 'Xen backend support')
 option('xen_pci_passthrough', type: 'feature', value: 'auto',
        description: 'Xen PCI passthrough support')
-option('tcg', type: 'feature', value: 'auto',
+option('tcg', type: 'combo', value: 'enabled',
+       choices: ['enabled', 'disabled', 'module'],
        description: 'TCG support')
 option('tcg_interpreter', type: 'boolean', value: false,
        description: 'TCG with bytecode interpreter (experimental and slow)')
diff --git a/scripts/minikconf.py b/scripts/minikconf.py
index bcd91015d3..2db0c3661f 100644
--- a/scripts/minikconf.py
+++ b/scripts/minikconf.py
@@ -323,6 +323,7 @@ def do_imply(self, var, symbol, cond=None):
 TOK_IF = 16;      TOKENS[TOK_IF] = '"if"';
 TOK_ID = 17;      TOKENS[TOK_ID] = 'identifier';
 TOK_EOF = 18;     TOKENS[TOK_EOF] = 'end of file';
+TOK_M = 19;       TOKENS[TOK_M] = '"m"';
 
 class KconfigParserError(Exception):
     def __init__(self, parser, msg, tok=None):
@@ -415,15 +416,18 @@ def do_include(self, include):
 
     # recursive descent parser -----
 
-    # y_or_n: Y | N
-    def parse_y_or_n(self):
+    # y_or_n_or_m: Y | N | M
+    def parse_y_or_n_or_m(self):
         if self.tok == TOK_Y:
             self.get_token()
             return True
         if self.tok == TOK_N:
             self.get_token()
             return False
-        raise KconfigParserError(self, 'Expected "y" or "n"')
+        if self.tok == TOK_M:
+            self.get_token()
+            return True
+        raise KconfigParserError(self, 'Expected "y", "n", or "m"')
 
     # var: ID
     def parse_var(self):
@@ -446,13 +450,13 @@ def parse_assignment_var(self):
         else:
             raise KconfigParserError(self, 'Expected identifier')
 
-    # assignment: var EQUAL y_or_n
+    # assignment: var EQUAL y_or_n_or_m
     def parse_assignment(self):
         var = self.parse_assignment_var()
         if self.tok != TOK_EQUAL:
             raise KconfigParserError(self, 'Expected "="')
         self.get_token()
-        self.data.do_assignment(var, self.parse_y_or_n())
+        self.data.do_assignment(var, self.parse_y_or_n_or_m())
 
     # primary: NOT primary
     #       | LPAREN expr RPAREN
@@ -505,7 +509,7 @@ def parse_condition(self):
     def parse_property(self, var):
         if self.tok == TOK_DEFAULT:
             self.get_token()
-            val = self.parse_y_or_n()
+            val = self.parse_y_or_n_or_m()
             cond = self.parse_condition()
             self.data.do_default(var, val, cond)
         elif self.tok == TOK_DEPENDS:
@@ -635,6 +639,8 @@ def scan_token(self):
             return TOK_Y
         elif self.tok == 'n' and self.check_keyword(""):
             return TOK_N
+        elif self.tok == 'm' and self.check_keyword(""):
+            return TOK_M
         elif (self.tok == 's' and self.check_keyword("ource")) or \
               self.tok == 'i' and self.check_keyword("nclude"):
             # source FILENAME
@@ -690,10 +696,10 @@ def scan_token(self):
     parser = KconfigParser(data)
     external_vars = set()
     for arg in argv[3:]:
-        m = re.match(r'^(CONFIG_[A-Z0-9_]+)=([yn]?)$', arg)
+        m = re.match(r'^(CONFIG_[A-Z0-9_]+)=([ynm]?)$', arg)
         if m is not None:
             name, value = m.groups()
-            parser.do_assignment(name, value == 'y')
+            parser.do_assignment(name, value == 'y' or value == 'm')
             external_vars.add(name[7:])
         else:
             fp = open(arg, 'rt', encoding='utf-8')
diff --git a/tests/meson.build b/tests/meson.build
index 55a7b08275..d3800989ee 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -80,7 +80,7 @@ if 'CONFIG_TCG' in config_all
   subdir('fp')
 endif
 
-if not get_option('tcg').disabled()
+if get_option('tcg') != 'disabled'
   if 'CONFIG_PLUGIN' in config_host
     subdir('plugin')
   endif
-- 
2.32.0


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 0/4] modules: add support for target-specific modules.

[Gerd Hoffmann]

On Mon, Jun 14, 2021 at 10:19:27PM +0000, José Ricardo Ziviani wrote:
> Hello Gerd,
> 
> On sexta-feira, 11 de junho de 2021 10:03:21 -03 Gerd Hoffmann wrote:
> >   Hi,
> > 
> > > Are there any pending patches to handle the remaining tcg dependencies
> > > in qemu?  When trying to build tcg modular (more than only
> > > tcg-accel-ops*) I get lots of unresolved symbols to tcg bits which are
> > > referenced directly (in cpu.c, gdbstub.c, monitor, ...).
> > > 
> > > The CONFIG_TCG=n case is handled either with stubs or with #ifdef
> > > CONFIG_TCG, which doesn't fly for modular tcg ...
> > 
> > So, enough for today, to be continued next week.
> > Work branch pushed to
> >     https://git.kraxel.org/cgit/qemu/log/?h=sirius/modinfo-playground
> > 
> > Topmost patch doesn't compile but shows the build changes.
> 
> I cloned your 'sirius/modinfo-playground-good' and started playing with the 
> command line options to build these modules. I would like to suggest to change 
> the current "--enable-X" with "--X=[enabled,disabled,module]", that seems to 
> make more sense for these modules. For instance:

Hmm, what would be the use case?  Right now qemu has the all-or-nothing
approach for modules, i.e. if modules are enabled everything we can
build as module will be built as module, and I havn't seen any drawbacks
so far.  So, why would one compile parts of qemu as module and other
parts not?

Also: when changing this I think it would be good to maintain backward
compatibility and use something like this:

  --enable-tcg=builtin
  --enable-tcg=module
  --enable-tcg (use default, probably "module" when modules
                are enabled and "builtin" otherwise)
  --disable-tcg

take care,
  Gerd

Re: [PATCH 0/4] modules: add support for target-specific modules.

[José Ricardo Ziviani]

[-- Attachment #1: Type: text/plain, Size: 2501 bytes --]

On terça-feira, 15 de junho de 2021 02:09:30 -03 Gerd Hoffmann wrote:
> On Mon, Jun 14, 2021 at 10:19:27PM +0000, José Ricardo Ziviani wrote:
> > Hello Gerd,
> > 
> > On sexta-feira, 11 de junho de 2021 10:03:21 -03 Gerd Hoffmann wrote:
> > >   Hi,
> > >   
> > > > Are there any pending patches to handle the remaining tcg dependencies
> > > > in qemu?  When trying to build tcg modular (more than only
> > > > tcg-accel-ops*) I get lots of unresolved symbols to tcg bits which are
> > > > referenced directly (in cpu.c, gdbstub.c, monitor, ...).
> > > > 
> > > > The CONFIG_TCG=n case is handled either with stubs or with #ifdef
> > > > CONFIG_TCG, which doesn't fly for modular tcg ...
> > > 
> > > So, enough for today, to be continued next week.
> > > Work branch pushed to
> > > 
> > >     https://git.kraxel.org/cgit/qemu/log/?h=sirius/modinfo-playground
> > > 
> > > Topmost patch doesn't compile but shows the build changes.
> > 
> > I cloned your 'sirius/modinfo-playground-good' and started playing with
> > the
> > command line options to build these modules. I would like to suggest to
> > change the current "--enable-X" with "--X=[enabled,disabled,module]",
> > that seems to
> > make more sense for these modules. For instance:
> Hmm, what would be the use case?  Right now qemu has the all-or-nothing
> approach for modules, i.e. if modules are enabled everything we can
> build as module will be built as module, and I havn't seen any drawbacks
> so far.  So, why would one compile parts of qemu as module and other
> parts not?

From my point of view, as a QEMU package maintainer, the all-or-nothing module 
approach is great - specially for accelerators - because we can create a set 
of officially supported packages and another set of optional modules, that 
users may get them if they want to.

However, please correct me if I'm wrong, I understand that an accelerator as a 
module will add an overhead that some user won't be willing to pay. So, give 
them the option to have built-in accelerators seems a good idea. Of course, I 
haven't measured anything yet so my opinion about it may be misleading.

> 
> Also: when changing this I think it would be good to maintain backward
> compatibility and use something like this:
> 
>   --enable-tcg=builtin
>   --enable-tcg=module
>   --enable-tcg (use default, probably "module" when modules
>                 are enabled and "builtin" otherwise)
>   --disable-tcg
> 

This is a better idea.

Thank you!!

> take care,
>   Gerd


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 0/4] modules: add support for target-specific modules.

[Gerd Hoffmann]

> > Hmm, what would be the use case?  Right now qemu has the all-or-nothing
> > approach for modules, i.e. if modules are enabled everything we can
> > build as module will be built as module, and I havn't seen any drawbacks
> > so far.  So, why would one compile parts of qemu as module and other
> > parts not?
> 
> From my point of view, as a QEMU package maintainer, the all-or-nothing module 
> approach is great - specially for accelerators - because we can create a set 
> of officially supported packages and another set of optional modules, that 
> users may get them if they want to.

Same here ;)

> However, please correct me if I'm wrong, I understand that an accelerator as a 
> module will add an overhead that some user won't be willing to pay. So, give 
> them the option to have built-in accelerators seems a good idea.

Modules add some overhead, yes, and there are surely use-cases where you
don't want accel modules.  I would just expect people don't want the
other modules either then, but maybe I'm wrong.

take care,
  Gerd

Re: [PATCH 0/4] modules: add support for target-specific modules.

[Claudio Fontana]

On 6/16/21 11:28 AM, Gerd Hoffmann wrote:
>>> Hmm, what would be the use case?  Right now qemu has the all-or-nothing
>>> approach for modules, i.e. if modules are enabled everything we can
>>> build as module will be built as module, and I havn't seen any drawbacks
>>> so far.  So, why would one compile parts of qemu as module and other
>>> parts not?
>>
>> From my point of view, as a QEMU package maintainer, the all-or-nothing module 
>> approach is great - specially for accelerators - because we can create a set 
>> of officially supported packages and another set of optional modules, that 
>> users may get them if they want to.
> 
> Same here ;)
> 
>> However, please correct me if I'm wrong, I understand that an accelerator as a 
>> module will add an overhead that some user won't be willing to pay. So, give 
>> them the option to have built-in accelerators seems a good idea.
> 
> Modules add some overhead, yes, and there are surely use-cases where you

Where do we expect the overhead to be, and of which nature?

Do we already know about such an impact?

Thanks,

CLaudio

> don't want accel modules.  I would just expect people don't want the
> other modules either then, but maybe I'm wrong.
> 
> take care,
>   Gerd
> 

Re: [PATCH 0/4] modules: add support for target-specific modules.

[Gerd Hoffmann]

  Hi,

> >> However, please correct me if I'm wrong, I understand that an accelerator as a 
> >> module will add an overhead that some user won't be willing to pay. So, give 
> >> them the option to have built-in accelerators seems a good idea.
> > 
> > Modules add some overhead, yes, and there are surely use-cases where you
> 
> Where do we expect the overhead to be, and of which nature?

The dynamic linking needed then when loading the module adds a bit of
overhead (compared to static linked code).  Increases qemu start time
a bit.

On the other hand the start overhead can be reduced by modules,
specifically for the case that a module depends on shared libraries and
is *not* needed.  With for example gtk being modular the gtk shared
libraries (plus indirect dependencies like pango, cairo etc) are only
loaded when you actually use gtk, whereas a non-modular build would load
them no matter what.

The code reorganization needed for modularization can add some overhead
too, when using function pointers instead of direct calls for example
(see QemuSpiceOps).  That overhead doesn't go away when you do a
non-modular build though ...

take care,
  Gerd

Re: [PATCH 0/4] modules: add support for target-specific modules.

[Claudio Fontana]

On 6/17/21 7:37 AM, Gerd Hoffmann wrote:
>   Hi,
> 
>>>> However, please correct me if I'm wrong, I understand that an accelerator as a 
>>>> module will add an overhead that some user won't be willing to pay. So, give 
>>>> them the option to have built-in accelerators seems a good idea.
>>>
>>> Modules add some overhead, yes, and there are surely use-cases where you
>>
>> Where do we expect the overhead to be, and of which nature?
> 
> The dynamic linking needed then when loading the module adds a bit of
> overhead (compared to static linked code).  Increases qemu start time
> a bit.
> 
> On the other hand the start overhead can be reduced by modules,
> specifically for the case that a module depends on shared libraries and
> is *not* needed.  With for example gtk being modular the gtk shared
> libraries (plus indirect dependencies like pango, cairo etc) are only
> loaded when you actually use gtk, whereas a non-modular build would load
> them no matter what.

Interesting observation.

> 
> The code reorganization needed for modularization can add some overhead
> too, when using function pointers instead of direct calls for example
> (see QemuSpiceOps).  That overhead doesn't go away when you do a
> non-modular build though ...
> 
> take care,
>   Gerd
> 

Do we need to be able to unload modules that we previously loaded? Or is this not a realistic requirement?

Thanks,

Claudio

Re: [PATCH 0/4] modules: add support for target-specific modules.

[Gerd Hoffmann]

  Hi,

> Do we need to be able to unload modules that we previously loaded? Or is this not a realistic requirement?

Surely doable, but it's work and needs infrastructure we don't have
right now.  We must be able to unregister everything modules can
register, which is only partly the case today.  We need usage counters
so we can figure whenever a module is in use or not.  Maybe more.

I don't see a use case justifying that work.

The linux kernel can unload modules (when enabled at build time), and
pretty much the only reason I've ever used that is device driver
development: test new driver version without reboot (as long as you
don't make a mistake which Oopses the kernel ...).

take care,
  Gerd

Re: [PATCH 0/4] modules: add support for target-specific modules.

[Claudio Fontana]

On 6/17/21 11:48 AM, Gerd Hoffmann wrote:
>   Hi,
> 
>> Do we need to be able to unload modules that we previously loaded? Or is this not a realistic requirement?
> 
> Surely doable, but it's work and needs infrastructure we don't have
> right now.  We must be able to unregister everything modules can
> register, which is only partly the case today.  We need usage counters
> so we can figure whenever a module is in use or not.  Maybe more.
> 
> I don't see a use case justifying that work.

If unloading a QEMU module is indeed not a requirement for QEMU itself, or frameworks which use it,
do we see optimization opportunities as a consequence?

> 
> The linux kernel can unload modules (when enabled at build time), and
> pretty much the only reason I've ever used that is device driver
> development: test new driver version without reboot (as long as you
> don't make a mistake which Oopses the kernel ...).
> 
> take care,
>   Gerd
> 

Ciao,

Claudio