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 065aed09ffef..6bb4ad915a1c 100644
--- a/util/module.c
+++ b/util/module.c
@@ -329,6 +329,9 @@ void module_load_qom_one(const char *type)
         if (!modinfo->objs) {
             continue;
         }
+        if (!module_check_arch(modinfo)) {
+            continue;
+        }
         for (sl = modinfo->objs; *sl != NULL; sl++) {
             if (strcmp(type, *sl) == 0) {
                 module_load_one("", modinfo->name, false);
@@ -349,6 +352,9 @@ void module_load_qom_all(void)
         if (!modinfo->objs) {
             continue;
         }
+        if (!module_check_arch(modinfo)) {
+            continue;
+        }
         module_load_one("", modinfo->name, false);
     }
     module_loaded_qom_all = true;
-- 
2.31.1

Hi,

(old patch)

On 24/6/21 12:38, Gerd Hoffmann wrote:
> 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.

"multiple modules implementing the same object." seems a design
mistake to me.

Assuming we clean the tree of target-specific modules "implementing
the same object" -- due to heterogeneous emulation --, is there
another use case for this check?

> 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 065aed09ffef..6bb4ad915a1c 100644
> --- a/util/module.c
> +++ b/util/module.c
> @@ -329,6 +329,9 @@ void module_load_qom_one(const char *type)
>           if (!modinfo->objs) {
>               continue;
>           }
> +        if (!module_check_arch(modinfo)) {
> +            continue;
> +        }
>           for (sl = modinfo->objs; *sl != NULL; sl++) {
>               if (strcmp(type, *sl) == 0) {
>                   module_load_one("", modinfo->name, false);
> @@ -349,6 +352,9 @@ void module_load_qom_all(void)
>           if (!modinfo->objs) {
>               continue;
>           }
> +        if (!module_check_arch(modinfo)) {
> +            continue;
> +        }
>           module_load_one("", modinfo->name, false);
>       }
>       module_loaded_qom_all = true;

On Tue, Aug 27, 2024 at 05:37:00PM GMT, Philippe Mathieu-Daudé wrote:
> Hi,
> 
> (old patch)
> 
> On 24/6/21 12:38, Gerd Hoffmann wrote:
> > 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.
> 
> "multiple modules implementing the same object." seems a design
> mistake to me.

IIRC that is (or was?) a problem with tcg or kvm modules, not fully sure
that ever happened in mainline qemu as the tcg modularization effort
stalled at some point.  But some object had the same name on all
architectures.  Which is not a problem when linked into
qemu-system-${arch} but is a problem when built as module.

> Assuming we clean the tree of target-specific modules "implementing
> the same object" -- due to heterogeneous emulation --,

Oh, yes, when linking multiple archs into one qemu binary the name
duplication is a problem even in the non-modular case.

> is there
> another use case for this check?

I don't think so.

take care,
  Gerd