On Fri, Oct 02, 2026 at 10:00:24AM +0800, 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. > > And also I have an idea about the set is_avaiable in an easy way. As > QOM basically > is a TREE, so for example x86_32 and x86_64 can share a same "i386" > base, all children's > is_avaiable inherent from parents is_avaiable, we can ensure every QOM > object have a > is_avaiable by update children is_avaiable from parents one. > > > > > @Yonggang: can you try to provide a RFC based on this, to see what it > > could look like? No need to cover all machines/cpus, just select one of > > machine+cpu, ideally with multiple SysEmuTarget (like virt and max cpu > > for aarch64), and let's iterate from this. > > > > @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. > > > > >> 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. > > > > > > > Fine for me. I am a bit skeptical this will be possible to catch all > > issues, but let's try! > > > > So, for existing binary: -M virt works as before. > > > > For new multi binary: > > $ qemu-system -M virt: > > Multiple machines were found, select one among: > > - aarch64-virt > > - riscv64-virt > > This would be very hard, that means QOM must be initialized. but we need > ensure the target is selected before the QOM init.
We don't need to have initialized anything. We just need a single global variable, whose default initializer is true vs false, for for the separate vs multi-target binaries. That's just a pair of .o files with a single bool variable, that we choose between when linking. 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 :|
