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

On 8/5/2026 1:20 PM, Pierrick Bouvier wrote:
> 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.

I talked with Mr. Pierrick and Mr. Phil and offered a hand in the riscv side.
So far I wasn't able to do much about it - qemu-riscv has been more active than
usual and we're barely keeping up with the reviews and ongoing work we want
to push for 11.2 ... I think we'll be in better shape for v1 of this effort.

Thanks,
Daniel




> 
>> 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