Re: [PATCH v3 01/10] machine: allow -M name to differ from QOM type

["Daniel P. Berrangé" <berrange@redhat.com>]

On Sat, Oct 03, 2026 at 12:27:08AM +0800, Yonggang Luo wrote:
> On Sat, Oct 3, 2026 at 12:14 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Thu, Oct 01, 2026 at 11:56:13AM -0700, Pierrick Bouvier wrote:
> > > On 10/1/2026 11:26 AM, Daniel P. Berrangé wrote:
> > > > On Thu, Oct 01, 2026 at 11:08:17AM -0700, Pierrick Bouvier wrote:
> > > >> On 10/1/2026 10:40 AM, Daniel P. Berrangé wrote:
> > > >>> 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)?
> > > >
> > > > It would require that we introduce a new field in MachineClass
> > > > that returned that information about what target a machine is
> > > > associated with.
> > > >
> > > > I note the SysEmuTarget covers both 32-bit and 64-bit variants.
> > > >
> > > > It might be better use QEMU_ARCH which correlates directly to
> > > > the TCG targets, rather than the traditional binary target
> > > > names ?
> > > >
> > > > Likely the CPU class would also want to declare its list of
> > > > supported targets.
> > > >
> > >
> > > QEMU_ARCH only represents base architectures, and not variant, so
> > > SysEmuTarget is the right choice.
> > >
> > > So, we would need a list of SysEmuTarget for every cpu/machine that is
> > > target specific, since one could be available for variants of base arch?
> >
> > Ok
> >
> > > @Daniel: how do we deal with machines available for all targets like
> > > null? We would need a way to ensure all machines/cpus are tagged
> > > correctly, in an independent way from "available for all", without
> > > having to repeat all existing SysEmuTarget.
> >
> > Or could the 'none' machine simply report '0xffffffff' for the
> > list of targets so it includes everything today & in the future,
> > or specialize "0" to mean everything ?
> I think for is_avaible give a
> bool target_is_any(const TargetInfo *ti)
> {
>     (void)ti;
>     return true;
> }
> is enough. then we iterate the target list we will found every target
> support for it.

Yep, that would work.


> > One idea I had was that when define the 'virt' class type we could
> > have a way to identify whether it is linked into the traditional
> > binaries, or linked into the multi-target binary, and from
> > that choose what name to register it under. eg
> >
> >   "extern bool multi_target;"
> 
> This idea already resolved,  see commit
> https://gitlab.com/lygstate-qemu/qemu/-/commit/3342c04451bb21174e6bd53a7040e4929008b9d0
> The idea is
> bool target_combined_binary(void)
> {
>     return true;
> }
> for multi-target binary, and stub for single-target binary
> for single-target binary
> bool target_combined_binary(void)
> {
>     return false;
> }

Ok, yes, that works, even if that feels a bit like overkill
vs a global variable !

> > and have two .c files, one setting it 'true' and one 'false',
> > and link each to the respective binaries. So we know statically
> > before main() has even run, what mode this binary is intended
> > to operate in.
> >
> > > Also, for compatibility with existing binaries, should we accept -M
> > > $arch-virt also? I feel like it does not hurt and would make thing
> > > simpler to switch between existing and new binary.
> >
> > Yes, that's another viable option. Always register '$arch-virt' and
> > only register 'virt' for traditional binaries.
> Oh, I see, for single-target binary, the "virt" is QOM name, and for
> multi-target binary.
> "$arch-virt" is the QOM name? So this series needs to consider this. made sense.



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 :|