On 10/11/26 1:22 PM, Yonggang Luo wrote:
On Fri, Oct 9, 2026 at 2:34 AM Pierrick Bouvier
<[email protected]> wrote:
On 10/8/2026 10:13 AM, Yonggang Luo wrote:
On Fri, Oct 9, 2026 at 12:06 AM Pierrick Bouvier
<[email protected]> wrote:
On 10/8/2026 2:46 AM, Yonggang Luo wrote:
On Thu, Oct 8, 2026 at 5:42 PM Daniel P. Berrangé <[email protected]> wrote:
On Wed, Oct 07, 2026 at 01:25:46PM -0700, Pierrick Bouvier wrote:
On 10/7/2026 4:47 AM, Yonggang Luo wrote:
This allows a combined binary to register machine types from all its targets.
Consequently, QMP `query-machines` can return machine entries from every
target, even when `none` is selected. For example, a client can query the
combined machine list with:
```json
{ "execute": "query-machines" }
```
The returned list includes the registered machine classes from all linked
targets. This is separate from selecting a machine: with `-target none`,
`-M virt` reports the targets that provide `virt` instead of choosing one
arbitrarily:
```text
qemu-system -target none -M virt
unsupported machine type: "virt" for target "none"
Available for targets:
aarch64
arm
```
From the long conversation on a previous thread, I thought we reached
the conclusion that if we didn't expose any ambiguous name, then -target
option is unnecessary, or maybe I got lost on track of this thread.
https://lore.kernel.org/qemu-devel/[email protected]/
I'm not sure which semantic we want to have with -target none. If there
is no ambiguous name registered, we just don't need it at all. It's a
win-win IMHO.
Yes, if we expose unique names for every machine, then -target is then
redundant.
so how to diff riscv32-virt and risv64-virt? oh so for this machine we
needs two name?
"virt" needs register twice for it? or register only a single time,
but we prefix the target_name()
automatically? for example machine::name === "virt", but we can use
"riscv32-virt" "risv64-virt" to reach it?
Yes, ideally we should have different variant of virt for 32/64 bit.
Same goes for cpu max types.
QOM type is always registered unambiguously ("$arch-virt"). Then, for
the "alias" name, which is virt, in case multiple matches are found,
command line can return an error with list of unambiguous names to call it.
$ qemu-system -M virt
Multiple virt machines are available. Please choose one of them:
- aarch64-virt
- riscv64-virt
There is no "parsing" of the argument, it's just the real QOM type. Then
we can find which target it implements from mc->targets.
And then, we can automatically choose which cpus should be available
based on that, thanks to cpu->targets.
For existing binaries, nothing change.
Good, I think we found a clean way now, is_available should be
removed, and TypeInfo::targets and TypeImpl::targets should be added.
It goes into MachineClass only for now.
I think
for "virt" we can add a shared hw/machine-virt.c instead, and forwarding to
the $arch specific virt. so that we only have a single "virt" registered.
And it's
targets is
QEMU_ARCH_I386 |
QEMU_ARCH_ARM |
QEMU_ARCH_RISCV |
QEMU_ARCH_LOONGARCH |
QEMU_ARCH_M68K |
QEMU_ARCH_OR1K |
QEMU_ARCH_XTENSA |
QEMU_ARCH_HEXAGON
So that we won't have a list of conflict QOM names for "virt" machines.
As now we indeed have only a single "virt" machine that redirects to
different targets.
The idea looks appealing, but I don't think it solves the problem to
have multiple virt variants available at the same time.
The "alias" idea you introduced before is good, we just need to add a
check if an alias is really unique, else return an error, as explained
previously.
If "-M aarch64-virt" works for both the new and existing binary, and -M
virt only for existing binaries (and ambiguous for new one), I think
that's a safe approach.
For other types also conflict can be handled in the same way, such as
"-cpu host" "-cpu max"
maybe others, but I think they all have the same way to deal with.
That's why TypeInfo::targets and TypeImpl::targets better than sole
Machine::targets
One step at a time.
Let's keep focused on declaring targets for a single machine first.
Then we can iterate to solve the "virt" problem.
Then convert all the existing machines and add a check in machine-target.c
Then, and only then, we can see what happens with cpus.
I tried this idea, but I faced a fatal error, because the
target_info() is not available until
the machine selected(the target arch will be select just along with
the machine selected), so basically
all calls to target_info() would raise an error(null pointer), how to
deal with it?
I see. Indeed, since we can't set a target before registering all types,
it implies that all the types class_init can't use target_* functions.
- register_accel_target_type
- cpu_max_v8_register_type
Regards,
Pierrick
