On Sat, Oct 3, 2026 at 12:14 AM Daniel P. Berrangé <[email protected]> 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.
> > > > > 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! > > I'm confident that we will find badly behaviour devices, > but we don't need to fix it all upfront, and they would > arguably be considered buggy already today. > > > >>> 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. > > Yes. > > > > 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? > > > 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; } > > 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 :| > -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo
