[PATCH 00/15] hw: expand DEFINE_MACHINE to explicit TypeInfo registration

[Yonggang Luo <luoyonggang@xxxxxxxxx>]

On Thursday, November 5, 2026, Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
>
> On Thu, Nov 05, 2026 at 12:27:18AM -0800, Pierrick Bouvier wrote:
> > On 11/3/2026 5:55 AM, Daniel P. Berrangé wrote:
> > > On Tue, Nov 03, 2026 at 09:48:44PM +0800, Yonggang Luo wrote:
> > >> On Tue, Nov 3, 2026 at 9:23 PM BALATON Zoltan <balaton@xxxxxxxxxx> wrote:
> > >>>
> > >>> On Tue, 3 Nov 2026, Yonggang Luo wrote:
> > >>> That means exposing all the boiler plate for all machines other than the
> > >>> simplest case. I think it would be better to keep 
> > >>> DEFINE_MACHINE_EXTENDED
> > >>> but maybe rethink the existing wrappers and drop unused ones and maybe 
> > >>> add
> > >>> new ones that reduce the usage of DEFINE_MACHINE_EXTENDED but still keep
> > >>> the boiler plate hidden.
> > >>
> > >> Thanks, I'll go this way, remove unused macros, and keep 
> > >> DEFINE_MACHINE_EXTENDED
> > >> and extend both DEFINE_MACHINE_EXTENDED DEFINE_MACHINE supports
> > >> "targets" or "arch_mask" parameter.
> > >
> > > Given that we don't need to do general per-arch type filtering in
> > > QOM, we could just move 'is_available' out of TypeInfo, and into the
> > > MachineClass, so it is a regular class level property, which can be
> > > set in the class_init methods, and thus avoid any changes to the
> > > DEFINE_MACHINE macros.
> > >
> >
> > Some cpus need it also, and it's used for filtering purpose at this time
> > (to avoid duplication at registration). We already depend on this behavior.
>
> Can you give me more info on the problem with the CPUs ? What cases
> have duplicate class names with CPUs ?



Hi, please take a look at this

https://lore.kernel.org/qemu-devel/20261031164009.2048-1-luoyonggang@xxxxxxxxx/

Also the single-binary RISC-V patches also faced the same issues,
trying to access
the target_info() in class_init that can be also avoided by this idea,
the bucket TypeImpl .

The patches is at:

https://lore.kernel.org/qemu-riscv/20260916-hw-riscv-cpu-int-v4-0-babc367b60f5@xxxxxx/

The riscv machine  need choose different cpu machine according to the
target in class_init ，

specifically
https://lore.kernel.org/qemu-riscv/20260916-hw-riscv-cpu-int-v4-1-babc367b60f5@xxxxxx/

https://lore.kernel.org/qemu-riscv/20260916-hw-riscv-cpu-int-v4-7-babc367b60f5@xxxxxx/

By the introduction of TypeBucket idea, these all can be resolved. and
we have no need to rename
The QOM typename at all.



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