On 10/15/2026 12:57 AM, Daniel P. Berrangé wrote: > On Thu, Oct 15, 2026 at 07:58:29AM +0200, Markus Armbruster wrote: >> Pierrick Bouvier <[email protected]> writes: >> >>> This series allows to link multiple targets that define >>> qmp_query_cpu_definitions. It simply replaces the duplicated definitions >>> with >>> target-specific ones and a single dispatcher. We didn't use yet the >>> dispatcher >>> pattern, and it's the first situation where it appears to be a good fit. >>> >>> A possible alternative would be to introduce this callback directly at >>> target-info level, which I think is a less desirable solution, since it >>> would >>> ties this API to monitor. >> >> I'm curious... why would such a tie be undesirable? > > I don't think target-info should be involved at all, it is a problem > to solve in the CPU type system. The CPU definitions are introspecting > sub-classes of TYPE_CPU. > > IMHO the right way to solve this is for CPUClass to gain a callback for > introspection, and for each target to provide an impl of that callback. > > There should only be a single qmp_query_cpu_definitions method that > introspects all registered TYPE_CPU subclasses. That way in a > multi-target binary, the introspection will return info for all > CPUs for all compiled in targets. >
I was wondering if what we would like to expose is all targets, or only the ones that have a cpu active. > That would need refactoring of the current qmp_query_cpu_definitions > methods which is a bigger job. This series as is, is a reasonable > small initial stepping stone to make it possible to link the binaries, > before a later followup patch to do the full refactoring to get the > desirable API semantics. > That was the goal 👍. > With regards, > Daniel Regards, Pierrick
