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


Reply via email to