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'
> > 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 > > Inferring from the binary name would be acceptable too, as that can > be thought of a syntax sugar for "-target aarch64". > > 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 :| > -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo
