On 10/8/2026 10:13 AM, Yonggang Luo wrote: > 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.
It goes into MachineClass only for now. > 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. > The idea looks appealing, but I don't think it solves the problem to have multiple virt variants available at the same time. The "alias" idea you introduced before is good, we just need to add a check if an alias is really unique, else return an error, as explained previously. If "-M aarch64-virt" works for both the new and existing binary, and -M virt only for existing binaries (and ambiguous for new one), I think that's a safe approach. > > 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 > One step at a time. Let's keep focused on declaring targets for a single machine first. Then we can iterate to solve the "virt" problem. Then convert all the existing machines and add a check in machine-target.c Then, and only then, we can see what happens with cpus. Regards, Pierrick
