[PATCH v2 0/2] single-binary: implement dynamic filtering for machine types

[PATCH v2 0/2] single-binary: implement dynamic filtering for machine types

[Pierrick Bouvier]

Now that we can link a single-binary with at least two targets (arm, aarch64),
we want to make sure that we expose the same set of machines (later devices and
cpus) than target binaries. For that, we implemented a static filtering based on
target interfaces that each machine will implement to declare which targets have
this machine.

However, we discovered that this static filtering is not enough. Indeed, some
machines and devices do not depend only on target, and their presence can depend
on Kconfig or host/target combination. Thus, our static approach can't work, and
we need something more flexible.

In v1:
This series adds a new TYPE_TARGET_SPECIFIC, that declare a single function
bool is_available(void). From there, any machine type (and later devices and
cpus) can implement it to override their presence for each target.
We first replace the existing static mechanism with this, and once done, we
cleanup all the old interface. One nice benefit is that we can get rid of
config/targets/*.c files, which saves duplication.
In v2:
Suggested by Daniel, we share a list of requirement for type to be available,
for future introspection needs.

This series was tested by comparing list of machines for all qemu system
binaries, before and after this change, to make sure we don't introduce a
regression.

v2
--

Changed the design to use a list of requirements instead of a callback.
Implement it on one machine to show usage and get feedback before going further.

Pierrick Bouvier (2):
  qom/object: add available_if field to TypeInfo
  remote/machine: add available_if for x-remote machine type

 hw/remote/machine.c        |  3 ++-
 include/qemu/target-info.h | 11 +++++++++++
 include/qom/object.h       |  5 +++++
 qom/object.c               | 10 ++++++++++
 rust/qom/src/qom.rs        |  1 +
 stubs/meson.build          |  1 +
 stubs/target-info.c        | 11 +++++++++++
 target-info.c              | 13 +++++++++++++
 8 files changed, 54 insertions(+), 1 deletion(-)
 create mode 100644 stubs/target-info.c

-- 
2.43.0

[PATCH v2 1/2] qom/object: add available_if field to TypeInfo

[Pierrick Bouvier]

With the single-binary, we start mixing types for different targets,
that may or may not be available for current one.

Previously, we implemented an approach based on interfaces, but it
proved to be too limited. It requires duplication between
machines/cpus/devices, and does not handle specific cases where a type
should be available based on a target configuration (Kconfig).

To solve this, we add a new field, available_if, to TypeInfo.
It is an array containing a list of requirements for type to be
available.

For now, we have only targets as requirements, but later we'll add
specific target config entries also.

We also add a TARGET_REQS macro, to declare a list of requirements. For
sanity sake, we don't use a complex variadic macro prefixing each
parameter. It requires a lot of macro boilerplate in C, and prevent
readers to jump easily to definition for each parameter.

Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
---
 include/qemu/target-info.h | 11 +++++++++++
 include/qom/object.h       |  5 +++++
 qom/object.c               | 10 ++++++++++
 rust/qom/src/qom.rs        |  1 +
 stubs/meson.build          |  1 +
 stubs/target-info.c        | 11 +++++++++++
 target-info.c              | 13 +++++++++++++
 7 files changed, 52 insertions(+)
 create mode 100644 stubs/target-info.c

diff --git a/include/qemu/target-info.h b/include/qemu/target-info.h
index 6c5b714288e..6379e65bbcf 100644
--- a/include/qemu/target-info.h
+++ b/include/qemu/target-info.h
@@ -50,6 +50,17 @@ const char *target_cpu_type(void);
  */
 bool target_big_endian(void);
 
+typedef enum TargetReq {
+    /* 0 is reserved for end of array */
+    TARGET_REQ_BASE_ARM = 1,
+    TARGET_REQ_AARCH64,
+    TARGET_REQ_ARM,
+} TargetReq;
+
+#define TARGET_REQS(...) (const TargetReq[]){__VA_ARGS__, 0}
+
+bool target_requirement(TargetReq Req);
+
 /**
  * target_base_arm:
  *
diff --git a/include/qom/object.h b/include/qom/object.h
index 11b1c9d2dc8..75bac929c14 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -24,6 +24,7 @@ typedef struct TypeInfo TypeInfo;
 
 typedef struct InterfaceClass InterfaceClass;
 typedef struct InterfaceInfo InterfaceInfo;
+typedef enum TargetReq TargetReq;
 
 #define TYPE_OBJECT "object"
 #define TYPE_CONTAINER "container"
@@ -469,6 +470,9 @@ struct Object
  * @class_data: Data to pass to the @class_init,
  *   @class_base_init. This can be useful when building dynamic
  *   classes.
+ * @available_if: List of requirements for type to be available. This
+ *   should point to a static array that's terminated with a zero filled
+ *   element.
  * @interfaces: The list of interfaces associated with this type.  This
  *   should point to a static array that's terminated with a zero filled
  *   element.
@@ -491,6 +495,7 @@ struct TypeInfo
     void (*class_base_init)(ObjectClass *klass, const void *data);
     const void *class_data;
 
+    const TargetReq *available_if;
     const InterfaceInfo *interfaces;
 };
 
diff --git a/qom/object.c b/qom/object.c
index 47977b1f440..02c5cd9d7b8 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -17,6 +17,7 @@
 #include "qom/object_interfaces.h"
 #include "qemu/cutils.h"
 #include "qemu/memalign.h"
+#include "qemu/target-info.h"
 #include "qapi/visitor.h"
 #include "qapi/string-input-visitor.h"
 #include "qapi/string-output-visitor.h"
@@ -172,6 +173,15 @@ static TypeImpl *type_register_internal(const TypeInfo *info)
 TypeImpl *type_register_static(const TypeInfo *info)
 {
     assert(info->parent);
+
+    if (info->available_if) {
+        for (const TargetReq *req = info->available_if; *req; ++req) {
+            if (!target_requirement(*req)) {
+                return NULL;
+            }
+        }
+    }
+
     return type_register_internal(info);
 }
 
diff --git a/rust/qom/src/qom.rs b/rust/qom/src/qom.rs
index cc00ddcfc98..f065df57542 100644
--- a/rust/qom/src/qom.rs
+++ b/rust/qom/src/qom.rs
@@ -691,6 +691,7 @@ pub trait ObjectImpl: ObjectType + IsA<Object> {
         class_init: Some(rust_class_init::<Self>),
         class_base_init: Self::CLASS_BASE_INIT,
         class_data: core::ptr::null(),
+        available_if: core::ptr::null(),
         interfaces: core::ptr::null(),
     };
 
diff --git a/stubs/meson.build b/stubs/meson.build
index 3b2f2680b19..dee2bc5a1a2 100644
--- a/stubs/meson.build
+++ b/stubs/meson.build
@@ -8,6 +8,7 @@ stub_ss.add(files('iothread-lock.c'))
 stub_ss.add(files('is-daemonized.c'))
 stub_ss.add(files('monitor-core.c'))
 stub_ss.add(files('replay-mode.c'))
+stub_ss.add(files('target-info.c'))
 stub_ss.add(files('trace-control.c'))
 
 if have_block
diff --git a/stubs/target-info.c b/stubs/target-info.c
new file mode 100644
index 00000000000..ab034e7a8d2
--- /dev/null
+++ b/stubs/target-info.c
@@ -0,0 +1,11 @@
+/*
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/target-info.h"
+
+bool target_requirement(TargetReq req)
+{
+    return true;
+}
diff --git a/target-info.c b/target-info.c
index 04c69c41f8a..a4ff24e021f 100644
--- a/target-info.c
+++ b/target-info.c
@@ -47,6 +47,19 @@ bool target_big_endian(void)
     return target_endian_mode() == ENDIAN_MODE_BIG;
 }
 
+bool target_requirement(TargetReq req)
+{
+    switch (req) {
+    case TARGET_REQ_BASE_ARM:
+        return target_base_arm();
+    case TARGET_REQ_AARCH64:
+        return target_aarch64();
+    case TARGET_REQ_ARM:
+        return target_arm();
+    }
+    g_assert_not_reached();
+}
+
 bool target_base_arm(void)
 {
     switch (target_arch()) {
-- 
2.43.0

Re: [PATCH v2 1/2] qom/object: add available_if field to TypeInfo

[Richard Henderson]

On 8/21/26 16:51, Pierrick Bouvier wrote:
> With the single-binary, we start mixing types for different targets,
> that may or may not be available for current one.
> 
> Previously, we implemented an approach based on interfaces, but it
> proved to be too limited. It requires duplication between
> machines/cpus/devices, and does not handle specific cases where a type
> should be available based on a target configuration (Kconfig).
> 
> To solve this, we add a new field, available_if, to TypeInfo.
> It is an array containing a list of requirements for type to be
> available.
> 
> For now, we have only targets as requirements, but later we'll add
> specific target config entries also.
> 
> We also add a TARGET_REQS macro, to declare a list of requirements. For
> sanity sake, we don't use a complex variadic macro prefixing each
> parameter. It requires a lot of macro boilerplate in C, and prevent
> readers to jump easily to definition for each parameter.
> 
> Signed-off-by: Pierrick Bouvier<pierrick.bouvier@oss.qualcomm.com>
> ---
>   include/qemu/target-info.h | 11 +++++++++++
>   include/qom/object.h       |  5 +++++
>   qom/object.c               | 10 ++++++++++
>   rust/qom/src/qom.rs        |  1 +
>   stubs/meson.build          |  1 +
>   stubs/target-info.c        | 11 +++++++++++
>   target-info.c              | 13 +++++++++++++
>   7 files changed, 52 insertions(+)
>   create mode 100644 stubs/target-info.c
> 
> diff --git a/include/qemu/target-info.h b/include/qemu/target-info.h
> index 6c5b714288e..6379e65bbcf 100644
> --- a/include/qemu/target-info.h
> +++ b/include/qemu/target-info.h
> @@ -50,6 +50,17 @@ const char *target_cpu_type(void);
>    */
>   bool target_big_endian(void);
>   
> +typedef enum TargetReq {
> +    /* 0 is reserved for end of array */
> +    TARGET_REQ_BASE_ARM = 1,
> +    TARGET_REQ_AARCH64,
> +    TARGET_REQ_ARM,
> +} TargetReq;
> +

Is there a reason you're inventing Yet Another Enum, especially when target_base_arm etc 
are based on SysEmuTarget, which itself is used to create bitmasks of targets?


r~

Re: [PATCH v2 1/2] qom/object: add available_if field to TypeInfo

[Pierrick Bouvier]

On 8/22/2026 7:23 AM, Richard Henderson wrote:
> On 8/21/26 16:51, Pierrick Bouvier wrote:
>> With the single-binary, we start mixing types for different targets,
>> that may or may not be available for current one.
>>
>> Previously, we implemented an approach based on interfaces, but it
>> proved to be too limited. It requires duplication between
>> machines/cpus/devices, and does not handle specific cases where a type
>> should be available based on a target configuration (Kconfig).
>>
>> To solve this, we add a new field, available_if, to TypeInfo.
>> It is an array containing a list of requirements for type to be
>> available.
>>
>> For now, we have only targets as requirements, but later we'll add
>> specific target config entries also.
>>
>> We also add a TARGET_REQS macro, to declare a list of requirements. For
>> sanity sake, we don't use a complex variadic macro prefixing each
>> parameter. It requires a lot of macro boilerplate in C, and prevent
>> readers to jump easily to definition for each parameter.
>>
>> Signed-off-by: Pierrick Bouvier<pierrick.bouvier@oss.qualcomm.com>
>> ---
>>   include/qemu/target-info.h | 11 +++++++++++
>>   include/qom/object.h       |  5 +++++
>>   qom/object.c               | 10 ++++++++++
>>   rust/qom/src/qom.rs        |  1 +
>>   stubs/meson.build          |  1 +
>>   stubs/target-info.c        | 11 +++++++++++
>>   target-info.c              | 13 +++++++++++++
>>   7 files changed, 52 insertions(+)
>>   create mode 100644 stubs/target-info.c
>>
>> diff --git a/include/qemu/target-info.h b/include/qemu/target-info.h
>> index 6c5b714288e..6379e65bbcf 100644
>> --- a/include/qemu/target-info.h
>> +++ b/include/qemu/target-info.h
>> @@ -50,6 +50,17 @@ const char *target_cpu_type(void);
>>    */
>>   bool target_big_endian(void);
>>   +typedef enum TargetReq {
>> +    /* 0 is reserved for end of array */
>> +    TARGET_REQ_BASE_ARM = 1,
>> +    TARGET_REQ_AARCH64,
>> +    TARGET_REQ_ARM,
>> +} TargetReq;
>> +
> 
> Is there a reason you're inventing Yet Another Enum, especially when
> target_base_arm etc are based on SysEmuTarget, which itself is used to
> create bitmasks of targets?
>

Mostly because we'll have to add CONFIG as TARGET_REQ. (CONFIG_NITRO for
instance, please see v1), in additions to targets.
My original implementation was using an interface with a callback, and I
offered to have this callback as part of TypeInfo. Daniel insisted on
having a list of constraints for (future) introspection purpose. I think
it's solving a problem we don't have yet, but need to move on on this
series, and happy to implement anything that satisfy the community.

In all cases, I'm open to other ideas if you have something to suggest,
which can represent both target and config knobs, with a simple and
concise solution. Enum was the best compromise for me, price being
duplication with existing SysEmuTarget.

> 
> r~
> 

Re: [PATCH v2 1/2] qom/object: add available_if field to TypeInfo

[Yonggang Luo]

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

On Mon, Aug 24, 2026 at 2:54 PM Pierrick Bouvier <
pierrick.bouvier@oss.qualcomm.com> wrote:
>
> On 8/22/2026 7:23 AM, Richard Henderson wrote:
> > On 8/21/26 16:51, Pierrick Bouvier wrote:
> >> With the single-binary, we start mixing types for different targets,
> >> that may or may not be available for current one.
> >>
> >> Previously, we implemented an approach based on interfaces, but it
> >> proved to be too limited. It requires duplication between
> >> machines/cpus/devices, and does not handle specific cases where a type
> >> should be available based on a target configuration (Kconfig).
> >>
> >> To solve this, we add a new field, available_if, to TypeInfo.
> >> It is an array containing a list of requirements for type to be
> >> available.
> >>
> >> For now, we have only targets as requirements, but later we'll add
> >> specific target config entries also.
> >>
> >> We also add a TARGET_REQS macro, to declare a list of requirements. For
> >> sanity sake, we don't use a complex variadic macro prefixing each
> >> parameter. It requires a lot of macro boilerplate in C, and prevent
> >> readers to jump easily to definition for each parameter.
> >>
> >> Signed-off-by: Pierrick Bouvier<pierrick.bouvier@oss.qualcomm.com>
> >> ---
> >>   include/qemu/target-info.h | 11 +++++++++++
> >>   include/qom/object.h       |  5 +++++
> >>   qom/object.c               | 10 ++++++++++
> >>   rust/qom/src/qom.rs        |  1 +
> >>   stubs/meson.build          |  1 +
> >>   stubs/target-info.c        | 11 +++++++++++
> >>   target-info.c              | 13 +++++++++++++
> >>   7 files changed, 52 insertions(+)
> >>   create mode 100644 stubs/target-info.c
> >>
> >> diff --git a/include/qemu/target-info.h b/include/qemu/target-info.h
> >> index 6c5b714288e..6379e65bbcf 100644
> >> --- a/include/qemu/target-info.h
> >> +++ b/include/qemu/target-info.h
> >> @@ -50,6 +50,17 @@ const char *target_cpu_type(void);
> >>    */
> >>   bool target_big_endian(void);
> >>   +typedef enum TargetReq {
> >> +    /* 0 is reserved for end of array */
> >> +    TARGET_REQ_BASE_ARM = 1,
> >> +    TARGET_REQ_AARCH64,
> >> +    TARGET_REQ_ARM,
> >> +} TargetReq;
> >> +
> >
> > Is there a reason you're inventing Yet Another Enum, especially when
> > target_base_arm etc are based on SysEmuTarget, which itself is used to
> > create bitmasks of targets?
> >
>
> Mostly because we'll have to add CONFIG as TARGET_REQ. (CONFIG_NITRO for
> instance, please see v1), in additions to targets.
> My original implementation was using an interface with a callback, and I
> offered to have this callback as part of TypeInfo. Daniel insisted on
> having a list of constraints for (future) introspection purpose. I think
> it's solving a problem we don't have yet, but need to move on on this
> series, and happy to implement anything that satisfy the community.
>
> In all cases, I'm open to other ideas if you have something to suggest,
> which can represent both target and config knobs, with a simple and
> concise solution. Enum was the best compromise for me, price being
> duplication with existing SysEmuTarget.
>
> >
> > r~
> >
>
>

I've implement single binary for arm/riscv at
https://patchew.org/QEMU/20260823150731.896-1-luoyonggang@gmail.com/

I do not see why this is needed yet.

My patches is based on
https://patchew.org/QEMU/20260724000948.234657-1-pierrick.bouvier@oss.qualcomm.com/
```
+
+static TargetCpuOps target_cpu_ops;
+
+void target_info_register_cpu_op(const char *cpu_type, size_t offset,
+                                 void *impl)
+{
+    const TargetInfo *ti = target_info();
+    void **slot;
+
+    g_assert(ti);
+    g_assert(offset + sizeof(void *) <= sizeof(TargetCpuOps));
+    g_assert((offset % sizeof(void *)) == 0);
+
+    if (strcmp(cpu_type, ti->cpu_type)) {
+        return;
+    }
+
+    slot = (void **)((char *)&target_cpu_ops + offset);
+    if (*slot) {
+        error_report("TargetCpuOps already registered for type '%s'
(offset %zu)",
+                     cpu_type, offset);
+        return;
+    }
+    *slot = impl;
+}
+
+const TargetCpuOps *target_info_cpu_ops(void)
+{
+    return &target_cpu_ops;
+}
````

To see different func for different arch

--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

[-- Attachment #2: Type: text/html, Size: 5696 bytes --]

Re: [PATCH v2 1/2] qom/object: add available_if field to TypeInfo

[Pierrick Bouvier]

On 8/24/2026 1:39 AM, Yonggang Luo wrote:
> 
> 
> On Mon, Aug 24, 2026 at 2:54 PM Pierrick Bouvier
> <pierrick.bouvier@oss.qualcomm.com
> <mailto:pierrick.bouvier@oss.qualcomm.com>> wrote:
>>
>> On 8/22/2026 7:23 AM, Richard Henderson wrote:
>> > On 8/21/26 16:51, Pierrick Bouvier wrote:
>> >> With the single-binary, we start mixing types for different targets,
>> >> that may or may not be available for current one.
>> >>
>> >> Previously, we implemented an approach based on interfaces, but it
>> >> proved to be too limited. It requires duplication between
>> >> machines/cpus/devices, and does not handle specific cases where a type
>> >> should be available based on a target configuration (Kconfig).
>> >>
>> >> To solve this, we add a new field, available_if, to TypeInfo.
>> >> It is an array containing a list of requirements for type to be
>> >> available.
>> >>
>> >> For now, we have only targets as requirements, but later we'll add
>> >> specific target config entries also.
>> >>
>> >> We also add a TARGET_REQS macro, to declare a list of requirements. For
>> >> sanity sake, we don't use a complex variadic macro prefixing each
>> >> parameter. It requires a lot of macro boilerplate in C, and prevent
>> >> readers to jump easily to definition for each parameter.
>> >>
>> >> Signed-off-by: Pierrick Bouvier<pierrick.bouvier@oss.qualcomm.com
> <mailto:pierrick.bouvier@oss.qualcomm.com>>
>> >> ---
>> >>   include/qemu/target-info.h | 11 +++++++++++
>> >>   include/qom/object.h       |  5 +++++
>> >>   qom/object.c               | 10 ++++++++++
>> >>   rust/qom/src/qom.rs        |  1 +
>> >>   stubs/meson.build          |  1 +
>> >>   stubs/target-info.c        | 11 +++++++++++
>> >>   target-info.c              | 13 +++++++++++++
>> >>   7 files changed, 52 insertions(+)
>> >>   create mode 100644 stubs/target-info.c
>> >>
>> >> diff --git a/include/qemu/target-info.h b/include/qemu/target-info.h
>> >> index 6c5b714288e..6379e65bbcf 100644
>> >> --- a/include/qemu/target-info.h
>> >> +++ b/include/qemu/target-info.h
>> >> @@ -50,6 +50,17 @@ const char *target_cpu_type(void);
>> >>    */
>> >>   bool target_big_endian(void);
>> >>   +typedef enum TargetReq {
>> >> +    /* 0 is reserved for end of array */
>> >> +    TARGET_REQ_BASE_ARM = 1,
>> >> +    TARGET_REQ_AARCH64,
>> >> +    TARGET_REQ_ARM,
>> >> +} TargetReq;
>> >> +
>> >
>> > Is there a reason you're inventing Yet Another Enum, especially when
>> > target_base_arm etc are based on SysEmuTarget, which itself is used to
>> > create bitmasks of targets?
>> >
>>
>> Mostly because we'll have to add CONFIG as TARGET_REQ. (CONFIG_NITRO for
>> instance, please see v1), in additions to targets.
>> My original implementation was using an interface with a callback, and I
>> offered to have this callback as part of TypeInfo. Daniel insisted on
>> having a list of constraints for (future) introspection purpose. I think
>> it's solving a problem we don't have yet, but need to move on on this
>> series, and happy to implement anything that satisfy the community.
>>
>> In all cases, I'm open to other ideas if you have something to suggest,
>> which can represent both target and config knobs, with a simple and
>> concise solution. Enum was the best compromise for me, price being
>> duplication with existing SysEmuTarget.
>>
>> >
>> > r~
>> >
>>
>>
> 
> I've implement single binary for arm/riscv at https://patchew.org/
> QEMU/20260823150731.896-1-luoyonggang@gmail.com/ <https://patchew.org/
> QEMU/20260823150731.896-1-luoyonggang@gmail.com/>
>

Thanks for giving it a try.

> I do not see why this is needed yet.
>

Try running -cpu help, or -device help after applying your series,
you'll notice it accidentally exposes all cpus/devices for all targets,
so it breaks the fundamental promise to keep existing command line
exactly as it is for current binaries.

That's why we're trying to solve this filtering issue for all QOM types
(machines, cpus and devices) *before* sending the series adding build
system for qemu-system + -target option (which I have, waiting on my
personal repo).

The v2 is a result of a discussion with Daniel on v1, you can read it
for details.

> My patches is based on  https://patchew.org/
> QEMU/20260724000948.234657-1-pierrick.bouvier@oss.qualcomm.com/
> <https://patchew.org/QEMU/20260724000948.234657-1-
> pierrick.bouvier@oss.qualcomm.com/>
> ```
> +
> +static TargetCpuOps target_cpu_ops;
> +
> +void target_info_register_cpu_op(const char *cpu_type, size_t offset,
> +                                 void *impl)
> +{
> +    const TargetInfo *ti = target_info();
> +    void **slot;
> +
> +    g_assert(ti);
> +    g_assert(offset + sizeof(void *) <= sizeof(TargetCpuOps));
> +    g_assert((offset % sizeof(void *)) == 0);
> +
> +    if (strcmp(cpu_type, ti->cpu_type)) {
> +        return;
> +    }
> +
> +    slot = (void **)((char *)&target_cpu_ops + offset);
> +    if (*slot) {
> +        error_report("TargetCpuOps already registered for type
> '%s' (offset %zu)",
> +                     cpu_type, offset);
> +        return;
> +    }
> +    *slot = impl;
> +}
> +
> +const TargetCpuOps *target_info_cpu_ops(void)
> +{
> +    return &target_cpu_ops;
> +}
> ````
> 
> To see different func for different arch
> 
> --
>          此致
> 礼
> 罗勇刚
> Yours
>     sincerely,
> Yonggang Luo

Regards,
Pierrick

Re: [PATCH v2 1/2] qom/object: add available_if field to TypeInfo

[Markus Armbruster]

Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:

> With the single-binary, we start mixing types for different targets,
> that may or may not be available for current one.
>
> Previously, we implemented an approach based on interfaces, but it
> proved to be too limited. It requires duplication between
> machines/cpus/devices, and does not handle specific cases where a type
> should be available based on a target configuration (Kconfig).
>
> To solve this, we add a new field, available_if, to TypeInfo.
> It is an array containing a list of requirements for type to be
> available.
>
> For now, we have only targets as requirements, but later we'll add
> specific target config entries also.
>
> We also add a TARGET_REQS macro, to declare a list of requirements. For
> sanity sake, we don't use a complex variadic macro prefixing each
> parameter. It requires a lot of macro boilerplate in C, and prevent
> readers to jump easily to definition for each parameter.
>
> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
> ---
>  include/qemu/target-info.h | 11 +++++++++++
>  include/qom/object.h       |  5 +++++
>  qom/object.c               | 10 ++++++++++
>  rust/qom/src/qom.rs        |  1 +
>  stubs/meson.build          |  1 +
>  stubs/target-info.c        | 11 +++++++++++
>  target-info.c              | 13 +++++++++++++
>  7 files changed, 52 insertions(+)
>  create mode 100644 stubs/target-info.c
>
> diff --git a/include/qemu/target-info.h b/include/qemu/target-info.h
> index 6c5b714288e..6379e65bbcf 100644
> --- a/include/qemu/target-info.h
> +++ b/include/qemu/target-info.h
> @@ -50,6 +50,17 @@ const char *target_cpu_type(void);
>   */
>  bool target_big_endian(void);
>  
> +typedef enum TargetReq {
> +    /* 0 is reserved for end of array */
> +    TARGET_REQ_BASE_ARM = 1,
> +    TARGET_REQ_AARCH64,
> +    TARGET_REQ_ARM,
> +} TargetReq;
> +
> +#define TARGET_REQS(...) (const TargetReq[]){__VA_ARGS__, 0}

The sentinel 0 is not a member of the enum.

Is this safe?  I'm asking because the C standard is infatuated with
undefined behavior.  Checking C99...  all I can find is Annex I "Common
warnings"

         -- A  value  is  given to an object of an enumeration type
            other than by assignment  of  an  enumeration  constant
            that  is  a  member  of  that  type,  or an enumeration
            variable that has the same type,  or  the  value  of  a
            function   that   returns  the  same  enumeration  type

Looks like it's safe.

[...]

Re: [PATCH v2 1/2] qom/object: add available_if field to TypeInfo

[Pierrick Bouvier]

On 8/23/2026 11:01 PM, Markus Armbruster wrote:
> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
> 
>> With the single-binary, we start mixing types for different targets,
>> that may or may not be available for current one.
>>
>> Previously, we implemented an approach based on interfaces, but it
>> proved to be too limited. It requires duplication between
>> machines/cpus/devices, and does not handle specific cases where a type
>> should be available based on a target configuration (Kconfig).
>>
>> To solve this, we add a new field, available_if, to TypeInfo.
>> It is an array containing a list of requirements for type to be
>> available.
>>
>> For now, we have only targets as requirements, but later we'll add
>> specific target config entries also.
>>
>> We also add a TARGET_REQS macro, to declare a list of requirements. For
>> sanity sake, we don't use a complex variadic macro prefixing each
>> parameter. It requires a lot of macro boilerplate in C, and prevent
>> readers to jump easily to definition for each parameter.
>>
>> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
>> ---
>>  include/qemu/target-info.h | 11 +++++++++++
>>  include/qom/object.h       |  5 +++++
>>  qom/object.c               | 10 ++++++++++
>>  rust/qom/src/qom.rs        |  1 +
>>  stubs/meson.build          |  1 +
>>  stubs/target-info.c        | 11 +++++++++++
>>  target-info.c              | 13 +++++++++++++
>>  7 files changed, 52 insertions(+)
>>  create mode 100644 stubs/target-info.c
>>
>> diff --git a/include/qemu/target-info.h b/include/qemu/target-info.h
>> index 6c5b714288e..6379e65bbcf 100644
>> --- a/include/qemu/target-info.h
>> +++ b/include/qemu/target-info.h
>> @@ -50,6 +50,17 @@ const char *target_cpu_type(void);
>>   */
>>  bool target_big_endian(void);
>>  
>> +typedef enum TargetReq {
>> +    /* 0 is reserved for end of array */
>> +    TARGET_REQ_BASE_ARM = 1,
>> +    TARGET_REQ_AARCH64,
>> +    TARGET_REQ_ARM,
>> +} TargetReq;
>> +
>> +#define TARGET_REQS(...) (const TargetReq[]){__VA_ARGS__, 0}
> 
> The sentinel 0 is not a member of the enum.
> 
> Is this safe?  I'm asking because the C standard is infatuated with
> undefined behavior.  Checking C99...  all I can find is Annex I "Common
> warnings"
> 
>          -- A  value  is  given to an object of an enumeration type
>             other than by assignment  of  an  enumeration  constant
>             that  is  a  member  of  that  type,  or an enumeration
>             variable that has the same type,  or  the  value  of  a
>             function   that   returns  the  same  enumeration  type
> 
> Looks like it's safe.
>

As far as I know, it's safe as long as the value you set can be hold in
underlying type (in C or C++) chosen by compiler. Obviously, 0 is a safe
choice for any storage type.

That's also why the compiler will warn you a function having this
pattern misses a return value:

typedef enum {
  A,
  B,
} Enum

int f(Enum myEnum) {
  switch(myEnum) {
  case A:
    return 16;
  case B:
    return 42;
  }
  /* => missing return value after switch, add default: or assert(0) */
}

Regards,
Pierrick

[PATCH v2 2/2] remote/machine: add available_if for x-remote machine type

[Pierrick Bouvier]

We don't remove yet existing interfaces to not break current binaries.

Signed-off-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>
---
 hw/remote/machine.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/remote/machine.c b/hw/remote/machine.c
index df08f640199..a62794dd2a0 100644
--- a/hw/remote/machine.c
+++ b/hw/remote/machine.c
@@ -152,7 +152,8 @@ static const TypeInfo remote_machine = {
         { TYPE_TARGET_AARCH64_MACHINE },
         { TYPE_TARGET_ARM_MACHINE },
         { }
-    }
+    },
+    .available_if = TARGET_REQS(TARGET_REQ_BASE_ARM)
 };
 
 static void remote_machine_register_types(void)
-- 
2.43.0

Re: [PATCH v2 0/2] single-binary: implement dynamic filtering for machine types

[Pierrick Bouvier]

On 8/21/2026 4:51 PM, Pierrick Bouvier wrote:
> Now that we can link a single-binary with at least two targets (arm, aarch64),
> we want to make sure that we expose the same set of machines (later devices and
> cpus) than target binaries. For that, we implemented a static filtering based on
> target interfaces that each machine will implement to declare which targets have
> this machine.
> 
> However, we discovered that this static filtering is not enough. Indeed, some
> machines and devices do not depend only on target, and their presence can depend
> on Kconfig or host/target combination. Thus, our static approach can't work, and
> we need something more flexible.
> 
> In v1:
> This series adds a new TYPE_TARGET_SPECIFIC, that declare a single function
> bool is_available(void). From there, any machine type (and later devices and
> cpus) can implement it to override their presence for each target.
> We first replace the existing static mechanism with this, and once done, we
> cleanup all the old interface. One nice benefit is that we can get rid of
> config/targets/*.c files, which saves duplication.
> In v2:
> Suggested by Daniel, we share a list of requirement for type to be available,
> for future introspection needs.
> 
> This series was tested by comparing list of machines for all qemu system
> binaries, before and after this change, to make sure we don't introduce a
> regression.
> 
> v2
> --
> 
> Changed the design to use a list of requirements instead of a callback.
> Implement it on one machine to show usage and get feedback before going further.
> 
> Pierrick Bouvier (2):
>   qom/object: add available_if field to TypeInfo
>   remote/machine: add available_if for x-remote machine type
> 
>  hw/remote/machine.c        |  3 ++-
>  include/qemu/target-info.h | 11 +++++++++++
>  include/qom/object.h       |  5 +++++
>  qom/object.c               | 10 ++++++++++
>  rust/qom/src/qom.rs        |  1 +
>  stubs/meson.build          |  1 +
>  stubs/target-info.c        | 11 +++++++++++
>  target-info.c              | 13 +++++++++++++
>  8 files changed, 54 insertions(+), 1 deletion(-)
>  create mode 100644 stubs/target-info.c
> 

Sent v3, using a callback in TypeInfo, as suggested by Richard.

https://lore.kernel.org/qemu-devel/20260828225901.367438-1-pierrick.bouvier@oss.qualcomm.com/T/#t

Regards,
Pierrick