On Thu, Oct 8, 2026 at 5:36 PM Daniel P. Berrangé <[email protected]> wrote:
>
> On Wed, Oct 07, 2026 at 05:00:06PM -0700, Pierrick Bouvier wrote:
> > On 10/7/2026 2:42 PM, Yonggang Luo wrote:
> > > On Thu, Oct 8, 2026 at 4:44 AM Pierrick Bouvier
> > > <[email protected]> wrote:
> > >>
> > >> On 10/7/2026 4:48 AM, Yonggang Luo wrote:
> > >>> Change TypeInfo.is_available to the new TypeIsAvailable type, which
> > >>> takes a const TargetInfo *. Registration passes target_info(), so
> > >>> behavior is unchanged. object.h only forward-declares TargetInfo.
> > >>>
> > >>> Switch the existing users (raspi, raspi4b, ast27x0 evb and fc) and the
> > >>> generated machine parents to the matching target_is_<arch> helpers.
> > >>>
> > >>> Signed-off-by: Yonggang Luo <[email protected]>
> > >>> ---
> > >>> hw/arm/aspeed_ast27x0-fc.c | 2 +-
> > >>> hw/arm/aspeed_ast27x0_evb.c | 4 ++--
> > >>> hw/arm/raspi.c | 4 ++--
> > >>> hw/arm/raspi4b.c | 2 +-
> > >>> hw/arm/virt.c | 4 ++--
> > >>> hw/m68k/virt.c | 4 ++--
> > >>> hw/or1k/virt.c | 2 +-
> > >>> include/qom/object.h | 12 +++++++++++-
> > >>> qom/object.c | 3 ++-
> > >>> 9 files changed, 24 insertions(+), 13 deletions(-)
>
> snip
>
> > >>> @@ -167,7 +168,7 @@ static TypeImpl *type_register_internal(const
> > >>> TypeInfo *info)
> > >>> abort();
> > >>> }
> > >>>
> > >>> - if (info->is_available && !info->is_available()) {
> > >>> + if (info->is_available && !info->is_available(target_info())) {
> > >>> return NULL;
> > >>> }
> > >>>
> > >>
> > >> ```
> > >> info->is_available(target_info())
> > >> ```
> > >>
> > >> or
> > >>
> > >> ```
> > >> is_available() {
> > >> TargetInfo ti * = target_info();
> > >> ...
> > >> }
> > >> ```
> > >>
> > >> Are doing the exact same thing today.
> > >>
> > >> So what is the future goal requiring to introduce this?
> > >
> > > From Daniel P. Berrangé's
> > > requesthttps://lore.kernel.org/qemu-devel/[email protected]/
> > > I forgot to mention that this is also pretty important for making
> > > introspection work, as we need to be able to say
> > >
> > > 'qemu-system --machine none -qmp ...'
> > >
> > > and connect to QMP to introspect the binary. Having to add a
> > > '--target <name>' into that mix is undesirable, as it creates
> > > a chicken & egg problem. You don't know what targets are built
> > > into qemu-system without introspecting it and you can't
> > > introspect it without selecting a target to introspect.
> > >
> > > From Pierrick's review
> > > https://lore.kernel.org/qemu-devel/[email protected]/So,
> > > for existing binary: -M virt works as before.
> > >
> > > For new multi binary:
> > > $ qemu-system -M virt:
> > > Multiple machines were found, select one among:
> > > - aarch64-virt
> > > - riscv64-virt
> > >
> > > Does it matches what you would expect?
> > >
> > > From Daniel's review
> > > https://lore.kernel.org/qemu-devel/[email protected]/
> > > We already have 'QemuTargetInfo' struct which is used
> > > with 'query-target', that should also be used with the
> > > new 'query-targets' command.
> > >
> > > We need to add the 'endianness' field to QemuTargetInfo.
> > >
> > > I don't think that we need to report machines though.
> > > We already have 'query-machines' which gives much broader
> > > information on the machines. "MachineInfo" needs to
> > > gain
> > >
> > > "targets": ["SysEmuTarget"]
> > >
> > > to list which target(s) a machine can be used with.
> > >
> > >
> > > To achieve these, we needs add TypeInfo parameter to it so that we can do
> > >
> > > static void report_unsupported_machine_type(const char *name, Error
> > > **errp)
> > > {
> > > g_autoptr(GSList) machines = machine_class_get_list(true);
> > > g_autoptr(GString) targets = g_string_new(NULL);
> > > TargetInfoNode *node;
> > > GSList *el;
> > >
> > > error_setg(errp, "unsupported machine type: \"%s\" for target \"%s\"",
> > > name, target_name());
> > > QLIST_FOREACH(node, target_info_list(), next) {
> > > for (el = machines; el; el = el->next) {
> > > MachineClass *mc = el->data;
> > >
> > > if ((!strcmp(mc->name, name) || !g_strcmp0(mc->alias, name))
> > > &&
> > >
> > > object_class_get_is_available(OBJECT_CLASS(mc))(node->info)) {
> > > g_string_append_printf(targets, " %s\n",
> > > node->info->target_name);
> > > break;
> > > }
> > > }
> > > }
> > > if (targets->len) {
> > > error_append_hint(errp, "Available for targets:\n%s",
> > > targets->str);
> > > }
> > > }
> > >
> > > That is we can iterate on all target-list, and check if it's can be
> > > fitlered.
> > >
> >
> > Ok, I finally see where this is going.
> >
> > So, based on all the previous conversations, we agreed to have a
> > qemu-system binary with all the QOM types available (for all targets).
>
> ack.
>
> > I personally think that if we go this way, we should not have any
> > -target option, and even less a -target none option.
>
> If we don't have a compelling need for -target to exist now, then
> dropping it as a concept is good.
>
> > The current is_available() approach was made with filtering per target
> > in mind, which predates where things are now. So, it's a good time to
> > reevaluate how to do it.
> >
> > This leaves us with (at least) two options:
> > - keep the callback and add TargetInfo parameter (what is done here)
> > - remove is_available, and adopt a more declarative approach
> >
> > How about we (re)-explore the second one?
> >
> > It's what we did in the past
> > (https://gitlab.com/qemu-project/qemu/-/commit/5de9216064d32eaac125dac4de1878486c16d73e),
> > and that I removed recently, in favor of is_available.
> > My rationale was that it was incomplete, since we needed to filter types
> > per config also, and not only target.
> > Now that direction is to not filter anything, filter per config is
> > unneeded, and switching back to declarative instead of callback makes
> > total sense. Using interfaces like we did has its own issues, and I
> > would not like to see this coming back.
> >
> > I'll do one very concrete proposal:
> >
> > ```
> > How about letting machines (and machines only first), have a new field
> > 'targets', being a uint32_t mask with an array of EMU_TARGET?
> > machine->targets = EMU_TARGET_X | EMU_TARGET_Y;
To be explicit state what, I give you a pseudo code to compute
machine->targets from TypeInfo::is_available(TargetInfo*)
let targets=0
foreach ti of TargetInfo list:
if (machine::TypeImpl::is_avaible(ti))
targets |= 1 << ti->target_arch
fi
endif
So they basically have equivalent effect, and is_available will handle
other code-needed condition properly such as
CPU/AccelClass. not restrict to targets, we can also attach the
KConfig into TargetInfo, so is_available(TargetInfo*)
also works for Kconfig. that's why I insist this way, it's solved all
the issues around.
so machine->targets = EMU_TARGET_X | EMU_TARGET_Y; is a good idea,
and it can be implemented with TypeInfo::is_available(TargetInfo*)
without much burden. and targets can be saved into a (machine or
TypeImpl) for fast access when needed, we can compute it
when the program starts.
> > ```
> >
> > @Daniel, IIUC, this is exactly the approach you proposed a few weeks
> > ago, just before I got frustrated and lost my patience against you. I
> > think it's more clear for me where you wanted to go. Sorry it took such
> > a large detour.
>
> Not a problem. We were coming at the debate with different ideas of
> where we were heading, so talking past each other at times.
>
> >
> > Yonggang, does that sounds good for you?
> > Daniel, does that sounds good for you also?
>
> Works for me.
>
> With regards,
> Daniel
> --
> |: https://berrange.com ~~ https://hachyderm.io/@berrange :|
> |: https://libvirt.org ~~ https://entangle-photo.org :|
> |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
>
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
