On Sat, Oct 03, 2026 at 12:27:08AM +0800, Yonggang Luo wrote: > 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.
Yep, that would work. > > 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; > } Ok, yes, that works, even if that feels a bit like overkill vs a global variable ! > > 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 :|
