On 3/24/25 11:46, Philippe Mathieu-Daudé wrote:
Since v1 (Thomas review comments)
- Move s390_set_qemu_cpu_model/s390_cpu_list to "cpu_models.h"
- Correct 'target/s390x: Register CPUClass:list_cpus' subject
'cpu_list' might be defined per target, and force code to be
built per-target. We can avoid that by introducing a CPUClass
callback.
This series combined with another which converts CPU_RESOLVING_TYPE
to a runtime helper, allows to move most of cpu-target to common.
I think we should focus on a more general solution, usable with
machines, cpus, and devices, like the interface based approached we
talked about.
Having an optional callback, implemented on half target, looks like a
half baked solution. And it would not be desirable to do the same thing
for machines, and devices later.
In case CPU_RESOLVING_TYPE is ambiguous (because 64 bit type inherit
from 32 bit type, like TYPE_AARCH64_CPU inherits from TYPE_ARM_CPU),
it's better to declare another interface, non ambiguous, like:
- TYPE_MACHINE_TARGET_AARCH64
- TYPE_MACHINE_TARGET_ARM
- TYPE_CPU_TARGET_AARCH64
- TYPE_CPU_TARGET_ARM
- TYPE_DEVICE_TARGET_AARCH64
- TYPE_DEVICE_TARGET_ARM
I would be in favor to introduce this for all targets, so all of them
are implemented in the exact same way, and the pattern is easy to follow.
By using this approach and tagging machines/cpus/devices accordingly,
there is no need for any callback anywhere, and the listing code can be
generic.
As a bonus, we can assert all machines/cpus are properly tagged,
something impossible to do with the callbacks approach, which opens room
for a possible error, if one of the callback is buggy.
