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. https://gitlab.com/lygstate-qemu/qemu/-/blob/combined-binary-multi-targets/tests/qtest/machine-option-test.c?ref_type=heads#L393 This is the tests example to demo this, and all tests are already passed that in combine of a multi_target_supported_targets = [ 'none-softmmu', 'aarch64-softmmu', 'arm-softmmu', 'i386-softmmu', 'microblaze-softmmu', 'riscv32-softmmu', 'riscv64-softmmu', 'x86_64-softmmu', ] I tried hard to get 'i386-softmmu' 'x86_64-softmmu' to work. As they are the most complicated targets. And now it works. so this patch series is fine. > > 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 > > A possible alternative could be to use ".is_available = target_X" on > those virt types, which will ensure only one is effectively registered > at runtime, thus, there is no ambiguity on name or who is the "virt" > machine. > > Again, I'm ok if anyone wants to pull this. > > Regards, > Pierrick -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo
