On Sat, Oct 3, 2026 at 12:17 AM Daniel P. Berrangé <[email protected]> wrote: > > 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.
Use functions have a better property that it won't be modified when running as it's not data. And using "extern bool multi_target;" is also fine. > > > 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
