On Fri, Oct 9, 2026 at 12:06 AM Pierrick Bouvier <[email protected]> wrote: > > On 10/8/2026 2:46 AM, Yonggang Luo wrote: > > On Thu, Oct 8, 2026 at 5:42 PM Daniel P. Berrangé <[email protected]> > > wrote: > >> > >> On Wed, Oct 07, 2026 at 01:25:46PM -0700, Pierrick Bouvier wrote: > >>> On 10/7/2026 4:47 AM, Yonggang Luo wrote: > >>>> This allows a combined binary to register machine types from all its > >>>> targets. > >>>> Consequently, QMP `query-machines` can return machine entries from every > >>>> target, even when `none` is selected. For example, a client can query the > >>>> combined machine list with: > >>>> > >>>> ```json > >>>> { "execute": "query-machines" } > >>>> ``` > >>>> > >>>> The returned list includes the registered machine classes from all linked > >>>> targets. This is separate from selecting a machine: with `-target none`, > >>>> `-M virt` reports the targets that provide `virt` instead of choosing one > >>>> arbitrarily: > >>>> > >>>> ```text > >>>> qemu-system -target none -M virt > >>>> unsupported machine type: "virt" for target "none" > >>>> Available for targets: > >>>> aarch64 > >>>> arm > >>>> ``` > >>>> > >>> > >>> From the long conversation on a previous thread, I thought we reached > >>> the conclusion that if we didn't expose any ambiguous name, then -target > >>> option is unnecessary, or maybe I got lost on track of this thread. > >>> > >>> https://lore.kernel.org/qemu-devel/[email protected]/ > >>> > >>> I'm not sure which semantic we want to have with -target none. If there > >>> is no ambiguous name registered, we just don't need it at all. It's a > >>> win-win IMHO. > >> > >> Yes, if we expose unique names for every machine, then -target is then > >> redundant. > > > > so how to diff riscv32-virt and risv64-virt? oh so for this machine we > > needs two name? > > "virt" needs register twice for it? or register only a single time, > > but we prefix the target_name() > > automatically? for example machine::name === "virt", but we can use > > "riscv32-virt" "risv64-virt" to reach it? > > > > Yes, ideally we should have different variant of virt for 32/64 bit. > Same goes for cpu max types. > > QOM type is always registered unambiguously ("$arch-virt"). Then, for > the "alias" name, which is virt, in case multiple matches are found, > command line can return an error with list of unambiguous names to call it. > > $ qemu-system -M virt > Multiple virt machines are available. Please choose one of them: > - aarch64-virt > - riscv64-virt > > There is no "parsing" of the argument, it's just the real QOM type. Then > we can find which target it implements from mc->targets. > And then, we can automatically choose which cpus should be available > based on that, thanks to cpu->targets. > > For existing binaries, nothing change.
Good, I think we found a clean way now, is_available should be removed, and TypeInfo::targets and TypeImpl::targets should be added. I think for "virt" we can add a shared hw/machine-virt.c instead, and forwarding to the $arch specific virt. so that we only have a single "virt" registered. And it's targets is QEMU_ARCH_I386 | QEMU_ARCH_ARM | QEMU_ARCH_RISCV | QEMU_ARCH_LOONGARCH | QEMU_ARCH_M68K | QEMU_ARCH_OR1K | QEMU_ARCH_XTENSA | QEMU_ARCH_HEXAGON So that we won't have a list of conflict QOM names for "virt" machines. As now we indeed have only a single "virt" machine that redirects to different targets. For other types also conflict can be handled in the same way, such as "-cpu host" "-cpu max" maybe others, but I think they all have the same way to deal with. That's why TypeInfo::targets and TypeImpl::targets better than sole Machine::targets > > >> > >> 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
