On 10/1/2026 10:40 AM, Daniel P. Berrangé wrote: > On Thu, Oct 01, 2026 at 09:19:48AM -0700, Pierrick Bouvier wrote: >> 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? > > *If* we take the starting assumption that the new multi-target > binary does not need to be a perfect replica of the existing > binaries, then filtering devices is creating extra work for > ourselves, to solve a problem that isn't especially important. >
Yes sure, just brainstorming here, to help Yonggang moving forward with a clear direction. > Even with the current per-target binaries there are countless > devices linked in which are incompatible / not usable with > certain machine types. A new multi-target binary with a union > of all devices will just be a bigger example of a scenario that > already has to be dealt with for today's binaries. > > So if we have that assumption that we don't need to do device > filtering, at that point, a --target option doesn't have as > big of a role to play. The machine type code knows what target(s) > it wants (1 or 2 targets depending on if there are 32 + 64 bit > varaints. The CPU model the user requests (if the CPU is not > hardcoded by the machine), determines 32 bit vs 64 bit. > How can we deduce this information (bitness or target for existing machines/cpus)? Also, how to deal with devices that are only available for some targets, but not others, depending on various Kconfig knobs? > A --target option (or similar -machine name,target=xxx) could > be used to dis-ambiguate between 'virt' machines if keeping > their user facing machine names as-is, or it could be used as > a way to be more explicit about the 32-bit vs 64-bit choice > and sanity checked against the CPU model choice. > We could also not register them as virt if more than one target is detected, so people have to call explicitly aarch64-virt. Would that be a possible way to move forward? > So overall "device filtering" or not is the key question to > decide IMHO. > Fine for me. Just want to see how things will be before spending the effort to review many patches when outcome is uncertain. > With regards, > Daniel
