On 10/1/2026 9:14 AM, Yonggang Luo wrote: > 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. >> >>> >>>> >>>> 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[] > This can be easy to implement and can be defer till the qemu-system-$arch > is symbolic link to qemu-system. > >> - enforce with CLI -target > > I want to post my personal options, I'll prefer the -target options as > it's far easier to implement than "-machine $arch:$machine". > -machine $arch:$machine is very complicated to implement correct. > >> - not expose any machine > > I think not exposing any machine in the command line is a good option, > as it's easier to > implement and clean for the user. But I think this series is still needed. > As we want the means to inspect all machines and devices for all > targets(that need all of them > to be registered into the QOM type hash table). >
It's not strictly needed to expose all types. -target can be parsed first, and influence what is visible from help (including -M help) also. Also, if we go down the -target option, we should decide if we expose all types or not, which means if we implement filtering or not. If we expose all the types, I'm not sure what -target is supposed to choose. Daniel, what do you think about this one? >> > >> Phil. > > >
