On Fri, Oct 2, 2026 at 2:56 AM Pierrick Bouvier
<[email protected]> 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?
For this, adding TargetInfo parameter to is_avaible callback will let us get the
list of SysEmuTarget for every cpu/machine. As we can iterate on all TargetInfo
then check if that TargetInfo is present for every cpu/machine.
And indeed for devices if you want. That's what my patches are already done.
And also I have an idea about the set is_avaiable in an easy way. As
QOM basically
is a TREE, so for example x86_32 and x86_64 can share a same "i386"
base, all children's
is_avaiable inherent from parents is_avaiable, we can ensure every QOM
object have a
is_avaiable by update children is_avaiable from parents one.
>
> @Yonggang: can you try to provide a RFC based on this, to see what it
> could look like? No need to cover all machines/cpus, just select one of
> machine+cpu, ideally with multiple SysEmuTarget (like virt and max cpu
> for aarch64), and let's iterate from this.
>
> @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.
>
> >> 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.
> >
>
> Fine for me. I am a bit skeptical this will be possible to catch all
> issues, but let's try!
>
> So, for existing binary: -M virt works as before.
>
> For new multi binary:
> $ qemu-system -M virt:
> Multiple machines were found, select one among:
> - aarch64-virt
> - riscv64-virt
This would be very hard, that means QOM must be initialized. but we need
ensure the target is selected before the QOM init. it's the current
qemu_init workflow
A possible solution with add TargetInfo parameter on is_avaible is
that we can listing
all machines that named with virt, and listing which targets support
"virt". For example
$qemu-system -M virt:
Multiple machines were found, select one among:
-target aarch64 -M virt
-target riscv64 -M virt
As for qemu-system -M virt:, default to none target. That means all
machines are registered
into QOM, so we can list all machines. to help us identify which
targets that those
machines belongs to
>
> Does it matches what you would expect?
>
> 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.
Same reason -M $arch-virt, indeed like -M $arch:virt, but $arch-virt
would be even harder.
Because "-" is a valid separator in machine names, ":" is not a valid
machine name.
So without init QOM, we can not reliably identify "$arch-virt" belongs
to which target.
>
> Regards,
> Pierrick
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
