Re: [PATCH 00/27] single-binary: implement dynamic filtering for machine types

On 8/5/2026 6:30 AM, Yonggang Luo wrote:
> 
> 
> On Fri, Jul 31, 2026 at 1:34 AM Pierrick Bouvier
> <[email protected]
> <mailto:[email protected]>> wrote:
>>
>> On 7/23/2026 5:09 PM, Pierrick Bouvier wrote:
>> > Now that we can link a single-binary with at least two targets (arm,
> aarch64),
>> > we want to make sure that we expose the same set of machines (later
> devices and
>> > cpus) than target binaries. For that, we implemented a static
> filtering based on
>> > target interfaces that each machine will implement to declare which
> targets have
>> > this machine.
>> >
>> > However, we discovered that this static filtering is not enough.
> Indeed, some
>> > machines and devices do not depend only on target, and their
> presence can depend
>> > on Kconfig or host/target combination. Thus, our static approach
> can't work, and
>> > we need something more flexible.
>> >
>> > This series adds a new TYPE_TARGET_SPECIFIC, that declare a single
> function
>> > bool is_available(void). From there, any machine type (and later
> devices and
>> > cpus) can implement it to override their presence for each target.
>> > We first replace the existing static mechanism with this, and once
> done, we
>> > cleanup all the old interface. One nice benefit is that we can get
> rid of
>> > config/targets/*.c files, which saves duplication.
>> >
>> > This series was tested by comparing list of machines for all qemu system
>> > binaries, before and after this change, to make sure we don't
> introduce a
>> > regression.
>> >
> 
> I am also tracing for this. So what's the shape of the final command line? 
>

I have those commits ready, but I would like to get filtering done
before so we can focus on command line independently.

Currently, what we have implemented is:
./build/qemu-system -target {arm,aarch64,microblaze}
Or
cp ./build/qemu-system ./build/qemu-system-{arm,aarch64,microblaze} and
there is no need to use -target in this case.

> Maybe we can at least get arm/arm64/riscv32/risv64/riscv32-be/risv64-be
> to be in a single binary.
>

v0 will be arm/arm64/microblaze.
risvc64 is a wip, it's not yet ready for integration.

> The -be is needed because gdbstub would need this to get gdb working
> fine. so the endian mode is important. arm/arm64 have nothing about be
> support yet, even though in spec also have
>  
> 
> 
>> > Pierrick Bouvier (27):
>> >   include/qemu/target-info-qom.h: declare TYPE_TARGET_SPECIFIC interface
>> >   hw/arm: implement TYPE_TARGET_SPECIFIC
>> >   target-info: add target_riscv32 and target_base_riscv
>> >   hw/riscv: implement TYPE_TARGET_SPECIFIC
>> >   target-info: add target_config_multiprocess
>> >   hw/remote/machine: remove unsupported arm target
>> >   hw/remote/machine: implement TYPE_TARGET_SPECIFIC
>> >   target-info: add target_config_xen
>> >   hw/arm/xen-pvh: implement TYPE_TARGET_SPECIFIC
>> >   hw/xenpv/xen_machine_pv: implement TYPE_TARGET_SPECIFIC
>> >   target-info: add target_config_nitro
>> >   hw/nitro/machine: implement TYPE_TARGET_SPECIFIC
>> >   target-info-qom: implement new machine filtering per target
>> >   target-info-qom: use TYPE_MACHINE instead of target_machine_typename
>> >   target-info: remove target_machine_typename
>> >   target-info-qom: add type_target_specific
>> >   hw/arm: remove TYPE_TARGET_{AARCH64,ARM}_MACHINE
>> >   hw/arm: remove {arm,arm_aarch64,aarch64}_machine_interfaces
>> >   include/hw/core/boards.h: add DEFINE_MACHINE_TARGET_SPECIFIC
>> >   hw/arm: remove DEFINE_MACHINE_{AARCH64,ARM}
>> >   hw/arm: remove machines-qom.h
>> >   hw/riscv: remove TYPE_TARGET_{RISCV32,RISCV64}_MACHINE
>> >   hw/riscv: remove {riscv32,riscv32_64,riscv64}_machine_interfaces
>> >   hw/riscv: remove DEFINE_MACHINE_{RISCV32,RISCV64}
>> >   hw/riscv: remove machines-qom.h
>> >   configs/targets: remove target info definitions
> 
>> >   target-info: rename target-info-stub.c in target-info-def.c
> 
> Does that mean  target-info-def.c would be compiled N-times. N is the
> target list count and finally linkage into a single binary?
> How to choose this target-info?
>

Yes, correct.
We choose either from -target arch, or from binary name.
In case a single target-info is present, we don't check binary name and
simply use it.

> 
>> >
>>
>> Gentle ping after a week.
>> You're welcome to review only your architecture if time is limited, and
>> validate the global approach.
>>
>> Regards,
>> Pierrick
>>
> 
> 
> --
>          此致
> 礼
> 罗勇刚
> Yours
>     sincerely,
> Yonggang Luo

Regards,
Pierrick