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. 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. 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. So overall "device filtering" or not is the key question to decide IMHO. 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 :|
