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

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

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

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 }
> 

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

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

  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

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

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

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

> > 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

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
> 

  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

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

  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

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

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
> 

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

  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