On 6/8/26 12:21, Daniel P. Berrangé wrote:
On Wed, Aug 05, 2026 at 12:10:27PM -0700, Pierrick Bouvier wrote:
On 8/5/2026 9:53 AM, Daniel P. Berrangé wrote:
On Wed, Aug 05, 2026 at 09:16:20AM -0700, Pierrick Bouvier wrote:
On 8/5/2026 7:05 AM, Daniel P. Berrangé wrote:
On Fri, Jul 24, 2026 at 12:09:21AM +0000, Pierrick Bouvier wrote:
In the next commits, We'll replace the logic to filter QOM types per
target from a static one (based on INTERFACES) to a runtime one, based
on is_available() function, that can be overriden per class.
Introduce the new interface we'll use for that.
Signed-off-by: Pierrick Bouvier <[email protected]>
---
include/qemu/target-info-qom.h | 15 +++++++++++++++
target-info-qom.c | 5 +++++
2 files changed, 20 insertions(+)
diff --git a/include/qemu/target-info-qom.h b/include/qemu/target-info-qom.h
index 91be415ed33..83eb537333b 100644
--- a/include/qemu/target-info-qom.h
+++ b/include/qemu/target-info-qom.h
@@ -14,6 +14,21 @@
#define TYPE_TARGET_INFO "target-info"
+#define TYPE_TARGET_SPECIFIC "target-specific"
+
+typedef struct TargetSpecific TargetSpecific;
+
+typedef struct TargetSpecificClass {
+ InterfaceClass parent_class;
+
+ bool (*is_available)(void);
+} TargetSpecificClass;
+
+#define TARGET_SPECIFIC(obj) \
+ INTERFACE_CHECK(TargetSpecific, (obj), TYPE_TARGET_SPECIFIC)
+DECLARE_CLASS_CHECKERS(TargetSpecificClass, TARGET_SPECIFIC,
+ TYPE_TARGET_SPECIFIC)
Looking through the series,I don't really see the point
in this interface. Why is this not possible to do by
adding 'is_available' to MachineClass. It would make
the rest of the series simpler and especially avoid the
need to introduced yet more series of macros for defining
machine classes.
We'll need the exact same interface for cpus, and devices also. IMHO, it
makes sense to have this in an external interface, instead of forcing it
to be present in all cpus/devices/machines. I also considered adding it
directly in Object class directly (would be the simplest), but I felt it
would be hard to motivate it.
I don't see a need for the common interface across cpus/devices/etc as
as code that's filtering only cares about the specific types. It also
definitely doesn't beloong in Object class, but the Object class could
be changed to make it simpler.
We agree on this.
The object_class_get_list() method could get a 'bool filter(ObjectClass *cl)'
callback which could be invoked on each class to filter it.
That said I find it pretty undesirable as an approach that we're
registering classes that can't then be used in a given situation.
This has a ripple effect where every bit of code that iterates over
classes needs changing to add filtering after the fact. It is also
not great for scalability, as it means every QEMU process will have
the union of all classes for all targets registered, most of which
have to be discarded / ignored at runtime.
This is inherent to the nature of having a single binary.
We need to cover those two requirements:
1. having a filter mechanism (per target)
2. have all the classes accessible for the heterogeneous machines that
will be coming in the future
1. could be covered by what you describe, however, it breaks 2. For
this, you need to be able to register all types by design.
Even the heterogeneous machines aren't going to need all the
classes from all 30+ targets that QEMU supports.
IIUC, the current approach relies on '--target <blah>' to select
which target we need. Would the heterogeneous machines not just
change that to allow "--target <this> --target <that>". It still
looks like we should be able to significantly limit what we
register for heterogeneous machines.
Heterogeneous binary won't filter anything at runtime (if we want
to filter components we already have Kconfig at compile time).
"--target <foo>" is only needed to have a single binary backward
compatible. If you use it, you fall back to single architecture
(our current binaries). If you want anything heterogeneous, you
can not use it. This will be by design.
