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