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? @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! >>> 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. > 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 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. > With regards, > Daniel Regards, Pierrick
