On Sat, Oct 3, 2026 at 12:35 AM Daniel P. Berrangé <[email protected]> wrote:
>
> 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 !
Forget to tell, the overkill is intentionally,for multi-target binary
is we want to compat the future that qemu-system-$arch is symlink to
qemu-system,
then we will need
bool target_combined_binary(void)
{
return program_name.ends("$arch");
}
>
> > > 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
