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

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

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.

> Also, how to deal with devices that are only available for some targets,
> but not others, depending on various Kconfig knobs?

IMHO just leave devices to raise an error when passed to '-device'
if not compatible with the requested machine.

eg this example from x86 world:

  $ qemu-system-x86_64 -M microvm -device xen-disk
  qemu-system-x86_64: -device xen-disk: No 'xen-bus' bus found for device 'xen-disk'

  $ qemu-system-x86_64 -M isapc -device virtio-net-pci
  qemu-system-x86_64: -device virtio-net-pci: No 'PCI' bus found for device 'virtio-net-pci'

Hopefully most devices have sane error reporting when they
find a dependancy they have is not satisfied by the machine,
but if some end up asserting with crashes that's not a
blocker. Those asserts can be turned into pretty error
messages at our leisure by whomever cares about improving
error diagnosis.

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

Yes, we could diverge in the naming of the machines for the
existing binary, vs the new multi-binary, and that could well
be the sanest & simplest option in fact.

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