On Thu, Oct 1, 2026 at 4:44 PM Philippe Mathieu-Daudé <[email protected]> wrote: > > On 1/10/26 10:13, Yonggang Luo wrote: > > On Thu, Oct 1, 2026 at 4:01 PM Daniel P. Berrangé <[email protected]> > > wrote: > >> > >> On Wed, Sep 30, 2026 at 09:23:50PM -0700, Pierrick Bouvier wrote: > >>> On 9/30/26 6:55 PM, Yonggang Luo wrote: > >>>> On Thu, Oct 1, 2026 at 2:19 AM Pierrick Bouvier > >>>> <[email protected]> wrote: > >>>>> > >>>>> On 9/26/26 1:15 AM, Yonggang Luo wrote: > >>>>>> - Add machine_class_set_name() so boards can keep a stable -M name > >>>>>> when the QOM type is uniquified. machine_class_base_init still > >>>>>> defaults the name to the QOM type without -machine. > >>>>>> - Document that MachineClass::name is the -M name, not the QOM type. > >>>>>> - Sort -M help by MachineClass::name so order matches the printed names > >>>>>> when QOM types are prefixed (arm-virt-11.1-machine vs virt-11.1). > >>>>>> > >>>>>> Signed-off-by: Yonggang Luo <[email protected]> > >>>>>> Reviewed-by: Daniel P. Berrangé <[email protected]> > >>>>>> --- > >>>>>> hw/core/machine.c | 6 ++++++ > >>>>>> include/hw/core/boards.h | 12 +++++++++++- > >>>>>> system/vl.c | 8 +++----- > >>>>>> 3 files changed, 20 insertions(+), 6 deletions(-) > >>>>>> > >>>>> > >>>>> First, I'm not opposed to this series, and if anyone wants to pull this, > >>>>> I'm ok with that decision. It's just unclear for me what will be > >>>>> direction after this step. > >>>>> > >>>>> If I understand correctly, the goal here is to allow to register > >>>>> multiple "virt" machines, while still having distinct QOM types behind > >>>>> the hood, which does no affect behavior of current binaries who have > >>>>> only a single "virt" type at most. > >>>>> > >>>>> That said, if we project in the future where we have a binary with > >>>>> multiple of those "virt" machines, how will the current series help? The > >>>>> situation we'll have is distinct QOM types, that all answer to the name > >>>>> "virt", so we have no way to select them individually. > >>>>> > >>>>> Slightly worse, find_machine() will just pick the first machine name > >>>>> virt, which is a non-deterministic order at the moment. > >>>>> https://gitlab.com/qemu-project/qemu/-/blob/master/system/vl.c?ref_type=heads#L846 > >>>> > >>>> That will handle it properly. For single-target binary > >>>> qemu-system-$arch.exe, > >>>> this won't be an issue, as there is no conflict as they won't be > >>>> compiled in. > >>>> For multi-target binary qemu-system.exe, we will choose the target > >>>> through > >>>> -M $arch:$machine, and when no $arch is specified, the default to arch > >>>> to be "none", > >>>> so still won't be non-deterministic. > >>>> > >>> > >>>> "when no $arch is specified, the default to arch to be "none",so still > > >>> won't be non-deterministic. > >>> > >>> That's my point, the current abstraction will create something ambiguous > >>> by > >>> design. When people will specify -M virt, without $arch:, a random machine > >>> will be selected. At least, maybe this series should ensure there is only > >>> one virt alias, or make it forbidden and uses unambiguous names only. > >> > >> Yes, if there are multiple choices, we should not pick an arbitrary one > >> non-deterministically, we must require the user to narrow the choice > >> explicitly in some manner. > >> > >>> "$arch:" is just a workaround to not add -target option, except that it > >>> comes with additional problems, creating inconsistent command lines. > >>> I already expressed my skepticism about the "machine prefix" based > >>> approach, > >>> being more in favor to strongly filter types per target with an > >>> unambiguous > >>> -target option. I'll accept the community's choice on this, but just > >>> wanted > >>> to see this explained before someone hits the pull button on this series, > >>> so > >>> they know what will come down the road. > >> > >> Historically, QEMU do alot of things like this where we invented magic > >> syntax that needed custom parsing of the command line. Over time we > >> came to the conclusion this ad-hoc parsing was a bad idea, and we > >> should always explicitly model things, even if it is more verbose. > >> > >> Thus I would not want to see "$target:$machine" as something that is > >> parsed into two pieces. > >> > >> IOW, "aarch64-virt" would be OK as a unique name which treated as an > >> opaque string, but "aarch64:virt" as something split into "aarch64" > >> (target) and "virt" (machine) would be a bad idea. > >> > >> An acceptable way of modelling the latter would be to use > >> > >> '-machine name=virt,target=aarch64' > > Why mix target information parsing at machine level when the > machine already know it is target specific? People wanting to > use the ARM virt machine don't want to know (and don't care) > about the M68k virt machine.
Hi Philippe, Fair point. Users shouldn’t need to know about other targets to use ARM virt. Keep the machine name as virt; target selection in a combined binary should be separate from -machine. This series doesn’t choose that interface. With no target selected, help can list machines across targets, but QEMU must not choose one arbitrarily. > > > > >> > >> or > >> > >> -machine virt -target aarch64 > > > > > > That's made me confused, as different people propose different ways to > > handle it. > > Can we just choose one first? > > '-machine name=virt,target=aarch64' is introducing new options, so is > > '-machine virt -target aarch64' > > I can not argue which is better, my suggestion may land one first. Both > > "-machine virt -target aarch64" and "-machine $arch:$name" I have > > already implemented. And currently I chose > > "-machine $arch:$name" according to > > https://patchwork.ozlabs.org/project/qemu-devel/cover/[email protected]/#3749257 > > You still did not explained what you are trying to achieve > with all your contributions, so my view is surely biased by > what we envisioned 3 years ago when we started to pave our > way for heterogenous emulation. > > My options so far for a single binary: > > - infer from argv[] > - enforce with CLI -target > - not expose any machine > > That said I asked you multiple times what you are trying to > achieve to understand and get a consensus or pick the best > approach (we do not want to compete here, the point of the > community is to join efforts). > You are ignoring my questions, so this post is my last try > before I ignore you on your future contributions. Sorry if > it sounds unfriendly but you are about to reach the end of > my patience, exhausting my review time. > > If you have AI power, please have a look at semcode + lore > to dig in the mailing list archive and summarize the previous > work and discussions we had before offering distinct single > binary alternatives. > https://github.com/facebookexperimental/semcode/blob/main/docs/lore.md > Once installed and configured, you only need to run: > $ semcode-index --lore qemu-devel/3 > > > > >> > >> Inferring from the binary name would be acceptable too, as that can > >> be thought of a syntax sugar for "-target aarch64". > > Yes. Better for my mental health to defer the merge of this work > to you Daniel, since you already had a look a reviewed it. But > please compare with Pierrick approach before doing so: > https://lore.kernel.org/qemu-devel/[email protected]/ Hi Philippe, You’re right: I haven’t clearly explained what I’m trying to achieve, and I’m sorry for not answering your questions sooner. My goal is specifically to let a combined binary list all target-specific machines when the target is none. This is for inspection, not for selecting an arbitrary machine to run. Today, linking machines from different targets hits QOM type-name conflicts. This series gives the machine classes unique QOM names while preserving their familiar machine names. Pierrick’s series adds targets to a single linked binary and filters machines according to the selected target. Its do not care about machine listing for target "none". These patches address that separate case and the QOM-name conflicts; they are not intended to conflict with Pierrick’s target-selection work. I’m not proposing argv-based target inference or a new -target interface in this series. qemu-system-$arch is currently a separate executable, not a symlink to qemu-system, so argv-based selection is outside this work. This series do not conflict with either "-target $arch -machine $machine" or "-machine $arch:$machine" > > Regards, > > Phil. -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo
