On Fri, Oct 02, 2026 at 08:40:54AM -0700, Pierrick Bouvier wrote: > On 10/1/2026 7:00 PM, Yonggang Luo wrote: > > 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. > > > > @Daniel: would that work for you? I feel like it limits the way to > introspect qom objects, but maybe not if we export the right thing on > QAPI side based on that.
"is_available" is probably a bit overkill as a mechanism for introspecting, when we just need to return a list of targets, Since we have that already we might as well use it initially though. > >> 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. > > > > From the conversation above, Daniel and I are not in favor to have any > kind of parsing based on this string. So either we'll pick virt, or the > real qom name, but not anything else. Yeah, I'm leaning more towards always exposing the $arch-virt names in all binaries, and also exposing 'virt' in the traditional binaries only. 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 :|
