On 4/7/25 06:59, Markus Armbruster wrote:
Philippe Mathieu-Daudé <phi...@linaro.org> writes:Display the CPU model in 'info cpus'. Example before: $ qemu-system-aarch64 -M xlnx-versal-virt -S -monitor stdio QEMU 10.0.0 monitor - type 'help' for more information (qemu) info cpus * CPU #0: thread_id=42924 CPU #1: thread_id=42924 CPU #2: thread_id=42924 CPU #3: thread_id=42924 (qemu) q and after: $ qemu-system-aarch64 -M xlnx-versal-virt -S -monitor stdio QEMU 10.0.50 monitor - type 'help' for more information (qemu) info cpus * CPU #0: thread_id=42916 (cortex-a72) CPU #1: thread_id=42916 (cortex-a72) CPU #2: thread_id=42916 (cortex-r5f) CPU #3: thread_id=42916 (cortex-r5f) (qemu) Signed-off-by: Philippe Mathieu-Daudé <phi...@linaro.org> Reviewed-by: Richard Henderson <richard.hender...@linaro.org> Reviewed-by: Zhao Liu <zhao1....@intel.com> Tested-by: Zhao Liu <zhao1....@intel.com> --- qapi/machine.json | 3 +++ hw/core/machine-hmp-cmds.c | 3 ++- hw/core/machine-qmp-cmds.c | 1 + 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/qapi/machine.json b/qapi/machine.json index 0650b8de71a..d5bbb5e367e 100644 --- a/qapi/machine.json +++ b/qapi/machine.json @@ -80,6 +80,8 @@ # # @thread-id: ID of the underlying host thread # +# @model: CPU model name (since 10.1) +# # @props: properties associated with a virtual CPU, e.g. the socket id # # @target: the QEMU system emulation target, which determines which @@ -91,6 +93,7 @@ 'base' : { 'cpu-index' : 'int', 'qom-path' : 'str', 'thread-id' : 'int', + 'model' : 'str', '*props' : 'CpuInstanceProperties', 'target' : 'SysEmuTarget' }, 'discriminator' : 'target', diff --git a/hw/core/machine-hmp-cmds.c b/hw/core/machine-hmp-cmds.c index c6325cdcaaa..65eeb5e9cc2 100644 --- a/hw/core/machine-hmp-cmds.c +++ b/hw/core/machine-hmp-cmds.c @@ -40,7 +40,8 @@ void hmp_info_cpus(Monitor *mon, const QDict *qdict)monitor_printf(mon, "%c CPU #%" PRId64 ":", active,cpu->value->cpu_index); - monitor_printf(mon, " thread_id=%" PRId64 "\n", cpu->value->thread_id); + monitor_printf(mon, " thread_id=%" PRId64 " (%s)\n", + cpu->value->thread_id, cpu->value->model); }qapi_free_CpuInfoFastList(cpu_list);diff --git a/hw/core/machine-qmp-cmds.c b/hw/core/machine-qmp-cmds.c index d82043e1c68..ab4fd1ec08a 100644 --- a/hw/core/machine-qmp-cmds.c +++ b/hw/core/machine-qmp-cmds.c @@ -47,6 +47,7 @@ CpuInfoFastList *qmp_query_cpus_fast(Error **errp) value->cpu_index = cpu->cpu_index; value->qom_path = object_get_canonical_path(OBJECT(cpu)); value->thread_id = cpu->thread_id; + value->model = cpu_model_from_type(object_get_typename(OBJECT(cpu)));if (mc->cpu_index_to_instance_props) {CpuInstanceProperties *props;Does the conversion from CPU type name to model name lose information?
Likely.
If yes, should we provide the type name at least in QMP?
OK.
Let me also try a different angle... what's the preferred thing for users of HMP and for users of QMP, CPU model name or CPU type name? Are there any commands that accept one, but not the other?
Likely. In particular the CLI expect model names for '-cpu', except when created as '-device' were the type name is expected...
Are there other commands that return one, but not the other?
QMP commands usually return the QOM type name, not the model. IMHO the external interface should be the CPU model name. Keeping it simple, an example could be "max". The internal interface (QOM type name) is used to compose the QOM model. Some types end verbose, such "riscv64-max-tcg". I expect such information to be more relevant to an experimented QEMU developer or in a bug report rather than exposed to the users. Anyway, I'll respin using type name for QMP and model name for HMP. Thanks, Phil.
