* [PATCH 0/4] modules: add support for target-specific modules. @ 2021-06-10 10:15 Gerd Hoffmann 2021-06-10 10:15 ` [PATCH 1/4] modules: factor out arch check Gerd Hoffmann ` (4 more replies) 0 siblings, 5 replies; 23+ messages in thread From: Gerd Hoffmann @ 2021-06-10 10:15 UTC (permalink / raw) To: qemu-devel Cc: Michael S. Tsirkin, Christian Schoenebeck, Greg Kurz, cfontana, jose.ziviani, pbonzini, 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 1/4] modules: factor out arch check 2021-06-10 10:15 [PATCH 0/4] modules: add support for target-specific modules Gerd Hoffmann @ 2021-06-10 10:15 ` Gerd Hoffmann 2021-06-10 10:15 ` [PATCH 2/4] modules: check arch on qom lookup Gerd Hoffmann ` (3 subsequent siblings) 4 siblings, 0 replies; 23+ messages in thread From: Gerd Hoffmann @ 2021-06-10 10:15 UTC (permalink / raw) To: qemu-devel Cc: Michael S. Tsirkin, Christian Schoenebeck, Greg Kurz, cfontana, jose.ziviani, pbonzini, 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 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH 2/4] modules: check arch on qom lookup 2021-06-10 10:15 [PATCH 0/4] modules: add support for target-specific modules Gerd Hoffmann 2021-06-10 10:15 ` [PATCH 1/4] modules: factor out arch check Gerd Hoffmann @ 2021-06-10 10:15 ` Gerd Hoffmann 2021-06-10 10:15 ` [PATCH 3/4] modules: target-specific module build infrastructure Gerd Hoffmann ` (2 subsequent siblings) 4 siblings, 0 replies; 23+ messages in thread From: Gerd Hoffmann @ 2021-06-10 10:15 UTC (permalink / raw) To: qemu-devel Cc: Michael S. Tsirkin, Christian Schoenebeck, Greg Kurz, cfontana, jose.ziviani, pbonzini, 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 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH 3/4] modules: target-specific module build infrastructure 2021-06-10 10:15 [PATCH 0/4] modules: add support for target-specific modules Gerd Hoffmann 2021-06-10 10:15 ` [PATCH 1/4] modules: factor out arch check Gerd Hoffmann 2021-06-10 10:15 ` [PATCH 2/4] modules: check arch on qom lookup Gerd Hoffmann @ 2021-06-10 10:15 ` Gerd Hoffmann 2021-06-10 10:15 ` [PATCH 4/4] modules: build virtio-9p modular Gerd Hoffmann 2021-06-10 10:34 ` [PATCH 0/4] modules: add support for target-specific modules Claudio Fontana 4 siblings, 0 replies; 23+ messages in thread From: Gerd Hoffmann @ 2021-06-10 10:15 UTC (permalink / raw) To: qemu-devel Cc: Michael S. Tsirkin, Christian Schoenebeck, Greg Kurz, cfontana, jose.ziviani, pbonzini, 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 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH 4/4] modules: build virtio-9p modular 2021-06-10 10:15 [PATCH 0/4] modules: add support for target-specific modules Gerd Hoffmann ` (2 preceding siblings ...) 2021-06-10 10:15 ` [PATCH 3/4] modules: target-specific module build infrastructure Gerd Hoffmann @ 2021-06-10 10:15 ` Gerd Hoffmann 2021-06-10 10:34 ` [PATCH 0/4] modules: add support for target-specific modules Claudio Fontana 4 siblings, 0 replies; 23+ messages in thread From: Gerd Hoffmann @ 2021-06-10 10:15 UTC (permalink / raw) To: qemu-devel Cc: Michael S. Tsirkin, Christian Schoenebeck, Greg Kurz, cfontana, jose.ziviani, pbonzini, 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 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH 0/4] modules: add support for target-specific modules. 2021-06-10 10:15 [PATCH 0/4] modules: add support for target-specific modules Gerd Hoffmann ` (3 preceding siblings ...) 2021-06-10 10:15 ` [PATCH 4/4] modules: build virtio-9p modular Gerd Hoffmann @ 2021-06-10 10:34 ` Claudio Fontana 2021-06-10 12:23 ` Gerd Hoffmann 4 siblings, 1 reply; 23+ messages in thread From: Claudio Fontana @ 2021-06-10 10:34 UTC (permalink / raw) To: Gerd Hoffmann, qemu-devel Cc: Michael S. Tsirkin, Christian Schoenebeck, Philippe Mathieu-Daudé, Greg Kurz, jose.ziviani, pbonzini 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/4] modules: add support for target-specific modules. 2021-06-10 10:34 ` [PATCH 0/4] modules: add support for target-specific modules Claudio Fontana @ 2021-06-10 12:23 ` Gerd Hoffmann 2021-06-10 13:10 ` Gerd Hoffmann 2021-06-10 13:12 ` Claudio Fontana 0 siblings, 2 replies; 23+ messages in thread From: Gerd Hoffmann @ 2021-06-10 12:23 UTC (permalink / raw) To: Claudio Fontana Cc: Michael S. Tsirkin, Christian Schoenebeck, qemu-devel, Greg Kurz, jose.ziviani, pbonzini, Philippe Mathieu-Daudé 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 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH 0/4] modules: add support for target-specific modules. 2021-06-10 12:23 ` Gerd Hoffmann @ 2021-06-10 13:10 ` Gerd Hoffmann 2021-06-10 13:12 ` Claudio Fontana 1 sibling, 0 replies; 23+ messages in thread From: Gerd Hoffmann @ 2021-06-10 13:10 UTC (permalink / raw) To: Claudio Fontana Cc: Michael S. Tsirkin, Christian Schoenebeck, Greg Kurz, qemu-devel, jose.ziviani, pbonzini, Philippe Mathieu-Daudé 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 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH 0/4] modules: add support for target-specific modules. 2021-06-10 12:23 ` Gerd Hoffmann 2021-06-10 13:10 ` Gerd Hoffmann @ 2021-06-10 13:12 ` Claudio Fontana 2021-06-11 7:35 ` Paolo Bonzini 1 sibling, 1 reply; 23+ messages in thread From: Claudio Fontana @ 2021-06-10 13:12 UTC (permalink / raw) To: Gerd Hoffmann Cc: Michael S. Tsirkin, Christian Schoenebeck, qemu-devel, Greg Kurz, jose.ziviani, pbonzini, Philippe Mathieu-Daudé 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 } > ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH 0/4] modules: add support for target-specific modules. 2021-06-10 13:12 ` Claudio Fontana @ 2021-06-11 7:35 ` Paolo Bonzini 2021-06-11 8:29 ` Gerd Hoffmann 0 siblings, 1 reply; 23+ messages in thread From: Paolo Bonzini @ 2021-06-11 7:35 UTC (permalink / raw) To: Claudio Fontana, Gerd Hoffmann Cc: Michael S. Tsirkin, Christian Schoenebeck, Greg Kurz, qemu-devel, jose.ziviani, Philippe Mathieu-Daudé 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/4] modules: add support for target-specific modules. 2021-06-11 7:35 ` Paolo Bonzini @ 2021-06-11 8:29 ` Gerd Hoffmann 2021-06-11 13:03 ` Gerd Hoffmann 2021-06-11 17:14 ` Paolo Bonzini 0 siblings, 2 replies; 23+ messages in thread From: Gerd Hoffmann @ 2021-06-11 8:29 UTC (permalink / raw) To: Paolo Bonzini Cc: Michael S. Tsirkin, Christian Schoenebeck, qemu-devel, Greg Kurz, Claudio Fontana, jose.ziviani, Philippe Mathieu-Daudé 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/4] modules: add support for target-specific modules. 2021-06-11 8:29 ` Gerd Hoffmann @ 2021-06-11 13:03 ` Gerd Hoffmann 2021-06-11 13:17 ` Claudio Fontana 2021-06-14 22:19 ` José Ricardo Ziviani 2021-06-11 17:14 ` Paolo Bonzini 1 sibling, 2 replies; 23+ messages in thread From: Gerd Hoffmann @ 2021-06-11 13:03 UTC (permalink / raw) To: Paolo Bonzini Cc: Michael S. Tsirkin, Christian Schoenebeck, Greg Kurz, qemu-devel, Claudio Fontana, jose.ziviani, Philippe Mathieu-Daudé 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/4] modules: add support for target-specific modules. 2021-06-11 13:03 ` Gerd Hoffmann @ 2021-06-11 13:17 ` Claudio Fontana 2021-06-14 22:19 ` José Ricardo Ziviani 1 sibling, 0 replies; 23+ messages in thread From: Claudio Fontana @ 2021-06-11 13:17 UTC (permalink / raw) To: Gerd Hoffmann, Paolo Bonzini Cc: Michael S. Tsirkin, Christian Schoenebeck, Greg Kurz, qemu-devel, jose.ziviani, Philippe Mathieu-Daudé 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 > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/4] modules: add support for target-specific modules. 2021-06-11 13:03 ` Gerd Hoffmann 2021-06-11 13:17 ` Claudio Fontana @ 2021-06-14 22:19 ` José Ricardo Ziviani 2021-06-15 5:09 ` Gerd Hoffmann 1 sibling, 1 reply; 23+ messages in thread From: José Ricardo Ziviani @ 2021-06-14 22:19 UTC (permalink / raw) To: Paolo Bonzini, Gerd Hoffmann Cc: Michael S. Tsirkin, Christian Schoenebeck, qemu-devel, Greg Kurz, Claudio Fontana, Philippe Mathieu-Daudé [-- 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 --] ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH 0/4] modules: add support for target-specific modules. 2021-06-14 22:19 ` José Ricardo Ziviani @ 2021-06-15 5:09 ` Gerd Hoffmann 2021-06-15 15:48 ` José Ricardo Ziviani 0 siblings, 1 reply; 23+ messages in thread From: Gerd Hoffmann @ 2021-06-15 5:09 UTC (permalink / raw) To: José Ricardo Ziviani Cc: Michael S. Tsirkin, Christian Schoenebeck, Greg Kurz, qemu-devel, Claudio Fontana, Paolo Bonzini, Philippe Mathieu-Daudé 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/4] modules: add support for target-specific modules. 2021-06-15 5:09 ` Gerd Hoffmann @ 2021-06-15 15:48 ` José Ricardo Ziviani 2021-06-16 9:28 ` Gerd Hoffmann 0 siblings, 1 reply; 23+ messages in thread From: José Ricardo Ziviani @ 2021-06-15 15:48 UTC (permalink / raw) To: Gerd Hoffmann Cc: Paolo Bonzini, Michael S. Tsirkin, Christian Schoenebeck, qemu-devel, Greg Kurz, Claudio Fontana, Philippe Mathieu-Daudé [-- 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 --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/4] modules: add support for target-specific modules. 2021-06-15 15:48 ` José Ricardo Ziviani @ 2021-06-16 9:28 ` Gerd Hoffmann 2021-06-16 12:23 ` Claudio Fontana 0 siblings, 1 reply; 23+ messages in thread From: Gerd Hoffmann @ 2021-06-16 9:28 UTC (permalink / raw) To: José Ricardo Ziviani Cc: Michael S. Tsirkin, Christian Schoenebeck, Greg Kurz, qemu-devel, Claudio Fontana, Paolo Bonzini, Philippe Mathieu-Daudé > > 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/4] modules: add support for target-specific modules. 2021-06-16 9:28 ` Gerd Hoffmann @ 2021-06-16 12:23 ` Claudio Fontana 2021-06-17 5:37 ` Gerd Hoffmann 0 siblings, 1 reply; 23+ messages in thread From: Claudio Fontana @ 2021-06-16 12:23 UTC (permalink / raw) To: Gerd Hoffmann, José Ricardo Ziviani Cc: Michael S. Tsirkin, qemu-devel, Christian Schoenebeck, Greg Kurz, Philippe Mathieu-Daudé, Paolo Bonzini 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 > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/4] modules: add support for target-specific modules. 2021-06-16 12:23 ` Claudio Fontana @ 2021-06-17 5:37 ` Gerd Hoffmann 2021-06-17 7:48 ` Claudio Fontana 0 siblings, 1 reply; 23+ messages in thread From: Gerd Hoffmann @ 2021-06-17 5:37 UTC (permalink / raw) To: Claudio Fontana Cc: Michael S. Tsirkin, Christian Schoenebeck, Greg Kurz, qemu-devel, José Ricardo Ziviani, Paolo Bonzini, Philippe Mathieu-Daudé 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/4] modules: add support for target-specific modules. 2021-06-17 5:37 ` Gerd Hoffmann @ 2021-06-17 7:48 ` Claudio Fontana 2021-06-17 9:48 ` Gerd Hoffmann 0 siblings, 1 reply; 23+ messages in thread From: Claudio Fontana @ 2021-06-17 7:48 UTC (permalink / raw) To: Gerd Hoffmann Cc: Michael S. Tsirkin, Christian Schoenebeck, Greg Kurz, qemu-devel, José Ricardo Ziviani, Paolo Bonzini, Philippe Mathieu-Daudé 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/4] modules: add support for target-specific modules. 2021-06-17 7:48 ` Claudio Fontana @ 2021-06-17 9:48 ` Gerd Hoffmann 2021-06-17 10:07 ` Claudio Fontana 0 siblings, 1 reply; 23+ messages in thread From: Gerd Hoffmann @ 2021-06-17 9:48 UTC (permalink / raw) To: Claudio Fontana Cc: Michael S. Tsirkin, Christian Schoenebeck, Greg Kurz, qemu-devel, José Ricardo Ziviani, Paolo Bonzini, Philippe Mathieu-Daudé 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/4] modules: add support for target-specific modules. 2021-06-17 9:48 ` Gerd Hoffmann @ 2021-06-17 10:07 ` Claudio Fontana 0 siblings, 0 replies; 23+ messages in thread From: Claudio Fontana @ 2021-06-17 10:07 UTC (permalink / raw) To: Gerd Hoffmann Cc: Daniel P. Berrangé, Michael S. Tsirkin, Christian Schoenebeck, Greg Kurz, qemu-devel, José Ricardo Ziviani, Paolo Bonzini, Philippe Mathieu-Daudé 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/4] modules: add support for target-specific modules. 2021-06-11 8:29 ` Gerd Hoffmann 2021-06-11 13:03 ` Gerd Hoffmann @ 2021-06-11 17:14 ` Paolo Bonzini 1 sibling, 0 replies; 23+ messages in thread From: Paolo Bonzini @ 2021-06-11 17:14 UTC (permalink / raw) To: Gerd Hoffmann Cc: Michael S. Tsirkin, Christian Schoenebeck, Greg Kurz, qemu-devel, Claudio Fontana, jose.ziviani, Philippe Mathieu-Daudé 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2021-06-17 10:27 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-06-10 10:15 [PATCH 0/4] modules: add support for target-specific modules Gerd Hoffmann 2021-06-10 10:15 ` [PATCH 1/4] modules: factor out arch check Gerd Hoffmann 2021-06-10 10:15 ` [PATCH 2/4] modules: check arch on qom lookup Gerd Hoffmann 2021-06-10 10:15 ` [PATCH 3/4] modules: target-specific module build infrastructure Gerd Hoffmann 2021-06-10 10:15 ` [PATCH 4/4] modules: build virtio-9p modular Gerd Hoffmann 2021-06-10 10:34 ` [PATCH 0/4] modules: add support for target-specific modules Claudio Fontana 2021-06-10 12:23 ` Gerd Hoffmann 2021-06-10 13:10 ` Gerd Hoffmann 2021-06-10 13:12 ` Claudio Fontana 2021-06-11 7:35 ` Paolo Bonzini 2021-06-11 8:29 ` Gerd Hoffmann 2021-06-11 13:03 ` Gerd Hoffmann 2021-06-11 13:17 ` Claudio Fontana 2021-06-14 22:19 ` José Ricardo Ziviani 2021-06-15 5:09 ` Gerd Hoffmann 2021-06-15 15:48 ` José Ricardo Ziviani 2021-06-16 9:28 ` Gerd Hoffmann 2021-06-16 12:23 ` Claudio Fontana 2021-06-17 5:37 ` Gerd Hoffmann 2021-06-17 7:48 ` Claudio Fontana 2021-06-17 9:48 ` Gerd Hoffmann 2021-06-17 10:07 ` Claudio Fontana 2021-06-11 17:14 ` Paolo Bonzini
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.