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. > 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. it's the current > qemu_init workflow > A possible solution with add TargetInfo parameter on is_avaible is > that we can listing > all machines that named with virt, and listing which targets support > "virt". For example > > $qemu-system -M virt: > Multiple machines were found, select one among: > -target aarch64 -M virt > -target riscv64 -M virt > > As for qemu-system -M virt:, default to none target. That means all > machines are registered > into QOM, so we can list all machines. to help us identify which > targets that those > machines belongs to > >> >> 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. >> >> Regards, >> Pierrick > > >
