On 28/9/26 12:57, Daniel P. Berrangé wrote:
On Mon, Sep 28, 2026 at 06:51:41PM +0800, Yonggang Luo wrote:
On Mon, Sep 28, 2026 at 6:39 PM Philippe Mathieu-Daudé <
[email protected]> wrote:
On 28/9/26 12:13, Daniel P. Berrangé wrote:
On Sat, Sep 26, 2026 at 03:00:45PM +0800, Yonggang Luo wrote:
query-targets lists each linked target, including none, with its
arch, endianness, and the machines that target accepts.
Signed-off-by: Yonggang Luo <[email protected]>
---
hw/core/machine-qmp-cmds.c | 30 ++++++++++++++++++++++++++++++
qapi/machine.json | 35 +++++++++++++++++++++++++++++++++++
2 files changed, 65 insertions(+)
diff --git a/qapi/machine.json b/qapi/machine.json
index 6aaa2af709a..d8cdea6203e 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -307,6 +307,41 @@
##
{ 'command': 'query-target', 'returns': 'QemuTargetInfo' }
+##
+# @TargetMachines:
+#
+# One registered system target and the machines that can run on it.
+#
+# @arch: the target architecture
+#
+# @endianness: the target endianness
+#
+# @machines: machine type names, not aliases
+#
+# Since: 11.2
+##
+{ 'struct': 'TargetMachines',
+ 'data': { 'arch': 'SysEmuTarget',
+ 'endianness': 'EndianMode',
+ 'machines': ['str'] } }
We already have 'QemuTargetInfo' struct which is used
with 'query-target', that should also be used with the
new 'query-targets' command.
We need to add the 'endianness' field to QemuTargetInfo.
Why do we want to expose endianness, and what endianness to
expose? Endianness is a runtime bit state of CPUs. Sometime
this bit is hardwired but that is an implementation detail.
For some targets it's, but for some targets it's not. for example
mips-softmmu.mak
mipsel-softmmu.mak
mips64el-softmmu.mak
mips64-softmmu.mak
mips64el-softmmu.mak
mips64-softmmu.mak
only differ the endianless
"EndianMode" is a tri-state including 'unspecified' as a value,
so we can cope with both scenarios - the targets where endianness
is runtime switchable in the CPU can use 'unspecified' as the
EndianMode. That behaviour should be documented in the QAPI
docs for QemuTargetInfo
OK but still I don't understand the usefulness of exposing that
at the machine level, since this is a CPU property.
Machine != QEMU binary.
Are you trying to expose binary properties to management layer?
Can you explain the use case?