- Devel - libvirt List Archives

[PATCH 0/2] remove deprecated 'reconnect' options
by Vladimir Sementsov-Ogievskiy 10 Oct '25

10 Oct '25

They were deprecated in 9.2, now we can remove them. New options to use are reconnect-ms. v2: fixup docs and error messages Vladimir Sementsov-Ogievskiy (2): chardev: remove deprecated 'reconnect' option net/stream: remove deprecated 'reconnect' option chardev/char-socket.c | 24 +++++------------------- chardev/char.c | 3 --- docs/about/deprecated.rst | 15 --------------- docs/about/removed-features.rst | 22 ++++++++++++++++++++++ net/stream.c | 20 +++++--------------- qapi/char.json | 14 +------------- qapi/net.json | 13 +------------ 7 files changed, 34 insertions(+), 77 deletions(-) -- 2.48.1

6 13

[PATCH v2 0/7] tcg/mips: Remove support for 32-bit hosts
by Philippe Mathieu-Daudé 10 Oct '25

10 Oct '25

Since v1: - Removed N32/O32 ABIs (rth) - Do not remove tgen_qemu_ld2/st2 32-bit hosts are deprecated since v10.0. 2 releases later (as of v10.2) we can remove such code. Start with MIPS TCG backend. Remove related buildsys and testing. Philippe Mathieu-Daudé (7): docker: Remove 32-bit MIPS toolchain from debian-all-test image gitlab: Stop cross-testing for 32-bit MIPS hosts docker: Stop building 32-bit MIPS images tcg/mips: Remove support for O32 and N32 ABIs tcg/mips: Remove support for 32-bit hosts kvm/mips: Remove support for 32-bit hosts buildsys: Remove support for 32-bit MIPS hosts docs/about/deprecated.rst | 13 +- docs/about/removed-features.rst | 6 + configure | 9 - meson.build | 2 - tcg/mips/tcg-target-has.h | 2 - tcg/mips/tcg-target-reg-bits.h | 9 +- tcg/mips/tcg-target.c.inc | 292 +++--------------- .gitlab-ci.d/container-cross.yml | 6 - .gitlab-ci.d/crossbuilds.yml | 14 - common-user/host/mips/safe-syscall.inc.S | 35 --- tests/docker/Makefile.include | 2 +- .../dockerfiles/debian-all-test-cross.docker | 4 - .../dockerfiles/debian-mipsel-cross.docker | 187 ----------- tests/lcitool/refresh | 5 - 14 files changed, 56 insertions(+), 530 deletions(-) delete mode 100644 tests/docker/dockerfiles/debian-mipsel-cross.docker -- 2.51.0

3 13

Re: [PATCH RFC V6 03/24] hw/arm/virt: Clamp 'maxcpus' as-per machine's vCPU deferred online-capability
by Igor Mammedov 09 Oct '25

09 Oct '25

On Thu, 9 Oct 2025 12:32:15 +0000 Miguel Luis <miguel.luis(a)oracle.com> wrote: > Hi Salil, > > > On 1 Oct 2025, at 01:01, salil.mehta(a)opnsrc.net wrote: > > > > From: Salil Mehta <salil.mehta(a)huawei.com> > > > > To support a vCPU hot-add–like model on ARM, the virt machine may be setup with > > more CPUs than are active at boot. These additional CPUs are fully realized in > > KVM and listed in ACPI tables from the start, but begin in a disabled state. > > They can later be brought online or taken offline under host or platform policy > > control. The CPU topology is fixed at VM creation time and cannot change > > dynamically on ARM. Therefore, we must determine precisely the 'maxcpus' value > > that applies for the full lifetime of the VM. > > > > On ARM, this deferred online-capable model is only valid if: > > - The GIC version is 3 or higher, and > > - Each non-boot CPU’s GIC CPU Interface is marked “online-capable” in its > > ACPI GICC structure (UEFI ACPI Specification 6.5, §5.2.12.14, Table 5.37 > > “GICC CPU Interface Flags”), and > > - The chosen accelerator supports safe deferred CPU online: > > * TCG with multi-threaded TCG (MTTCG) enabled > > * KVM (on supported hosts) > > * Not HVF or QTest > > > > This patch sizes the machine’s max-possible CPUs during VM init: > > - If all conditions are satisfied, retain the full set of CPUs corresponding > > to (`-smp cpus` + `-smp disabledcpus`), allowing the additional (initially > > disabled) CPUs to participate in later policy-driven online. > > - Otherwise, clamp the max-possible CPUs to the boot-enabled count > > (`-smp disabledcpus=0` equivalent) to avoid advertising CPUs the guest can > > never use. > > > > A new MachineClass flag, `has_online_capable_cpus`, records whether the machine > > supports deferred vCPU online. This is usable by other machine types as well. > > > By the definition of > > * @has_hotpluggable_cpus: > * If true, board supports CPUs creation with -device/device_add. > > in include/hw/boards.h It should be fine to rename it to has_pluggable_cpus. But we should add support to arm/virt for -device/device_add cpu_foo, to avoid awkward -device-set and mangling of -smp. device_add in arm/virt case probably should be limited non hotplug usecase. > seems one could take advantage of MachineClass's has_hotpluggable_cpus variable > instead of creating a new has_online_capable_cpus one. > (Again, IMHO ‘online capable’ is ACPI nomenclature and doesn’t need to be brought > in MachineClass’s) the issue with has_hotpluggable_cpus might be QMP ABI, where libvirt migh use it to figure out if certain command are supported. CCing libvirt to check if that would break something. > > Variable which would be initialized in machvirt_init on an assignment based on > GIC version and/or wether there's inactive CPUs and proceed from there anyways, > making the default assignment in machine_virt_class_init superfluous. > > We're at hw/arm/virt and we know these CPUs are administratively power state > coordinated so admin_power_state_supported can still be set there in the > presence of inactive CPUs. > > Thanks > Miguel > > > > > Signed-off-by: Salil Mehta <salil.mehta(a)huawei.com> > > --- > > hw/arm/virt.c | 84 ++++++++++++++++++++++++++++++--------------- > > include/hw/boards.h | 1 + > > 2 files changed, 57 insertions(+), 28 deletions(-) > > > > diff --git a/hw/arm/virt.c b/hw/arm/virt.c > > index ef6be3660f..76f21bd56a 100644 > > --- a/hw/arm/virt.c > > +++ b/hw/arm/virt.c > > @@ -2168,8 +2168,7 @@ static void machvirt_init(MachineState *machine) > > bool has_ged = !vmc->no_ged; > > unsigned int smp_cpus = machine->smp.cpus; > > unsigned int max_cpus = machine->smp.max_cpus; > > - > > - possible_cpus = mc->possible_cpu_arch_ids(machine); > > + DeviceClass *dc; > > > > /* > > * In accelerated mode, the memory map is computed earlier in kvm_type() > > @@ -2186,7 +2185,7 @@ static void machvirt_init(MachineState *machine) > > * we are about to deal with. Once this is done, get rid of > > * the object. > > */ > > - cpuobj = object_new(possible_cpus->cpus[0].type); > > + cpuobj = object_new(machine->cpu_type); > > armcpu = ARM_CPU(cpuobj); > > > > pa_bits = arm_pamax(armcpu); > > @@ -2201,6 +2200,57 @@ static void machvirt_init(MachineState *machine) > > */ > > finalize_gic_version(vms); > > > > + /* > > + * The maximum number of CPUs depends on the GIC version, or on how > > + * many redistributors we can fit into the memory map (which in turn > > + * depends on whether this is a GICv3 or v4). > > + */ > > + if (vms->gic_version == VIRT_GIC_VERSION_2) { > > + virt_max_cpus = GIC_NCPU; > > + } else { > > + virt_max_cpus = virt_redist_capacity(vms, VIRT_GIC_REDIST); > > + if (vms->highmem_redists) { > > + virt_max_cpus += virt_redist_capacity(vms, VIRT_HIGH_GIC_REDIST2); > > + } > > + } > > + > > + if ((tcg_enabled() && !qemu_tcg_mttcg_enabled()) || hvf_enabled() || > > + qtest_enabled() || vms->gic_version == VIRT_GIC_VERSION_2) { > > + max_cpus = machine->smp.max_cpus = smp_cpus; > > + if (mc->has_online_capable_cpus) { > > + if (vms->gic_version == VIRT_GIC_VERSION_2) { > > + warn_report("GICv2 does not support online-capable CPUs"); > > + } > > + mc->has_online_capable_cpus = false; > > + } > > + } > > + > > + if (mc->has_online_capable_cpus) { > > + max_cpus = smp_cpus + machine->smp.disabledcpus; > > + machine->smp.max_cpus = max_cpus; > > + } > > + > > + if (max_cpus > virt_max_cpus) { > > + error_report("Number of SMP CPUs requested (%d) exceeds max CPUs " > > + "supported by machine 'mach-virt' (%d)", > > + max_cpus, virt_max_cpus); > > + if (vms->gic_version != VIRT_GIC_VERSION_2 && !vms->highmem_redists) { > > + error_printf("Try 'highmem-redists=on' for more CPUs\n"); > > + } > > + > > + exit(1); > > + } > > + > > + dc = DEVICE_CLASS(object_class_by_name(machine->cpu_type)); > > + if (!dc) { > > + error_report("CPU type '%s' not registered", machine->cpu_type); > > + exit(1); > > + } > > + dc->admin_power_state_supported = mc->has_online_capable_cpus; > > + > > + /* uses smp.max_cpus to initialize all possible vCPUs */ > > + possible_cpus = mc->possible_cpu_arch_ids(machine); > > + > > if (vms->secure) { > > /* > > * The Secure view of the world is the same as the NonSecure, > > @@ -2235,31 +2285,6 @@ static void machvirt_init(MachineState *machine) > > vms->psci_conduit = QEMU_PSCI_CONDUIT_HVC; > > } > > > > - /* > > - * The maximum number of CPUs depends on the GIC version, or on how > > - * many redistributors we can fit into the memory map (which in turn > > - * depends on whether this is a GICv3 or v4). > > - */ > > - if (vms->gic_version == VIRT_GIC_VERSION_2) { > > - virt_max_cpus = GIC_NCPU; > > - } else { > > - virt_max_cpus = virt_redist_capacity(vms, VIRT_GIC_REDIST); > > - if (vms->highmem_redists) { > > - virt_max_cpus += virt_redist_capacity(vms, VIRT_HIGH_GIC_REDIST2); > > - } > > - } > > - > > - if (max_cpus > virt_max_cpus) { > > - error_report("Number of SMP CPUs requested (%d) exceeds max CPUs " > > - "supported by machine 'mach-virt' (%d)", > > - max_cpus, virt_max_cpus); > > - if (vms->gic_version != VIRT_GIC_VERSION_2 && !vms->highmem_redists) { > > - error_printf("Try 'highmem-redists=on' for more CPUs\n"); > > - } > > - > > - exit(1); > > - } > > - > > if (vms->secure && !tcg_enabled() && !qtest_enabled()) { > > error_report("mach-virt: %s does not support providing " > > "Security extensions (TrustZone) to the guest CPU", > > @@ -3245,6 +3270,9 @@ static void virt_machine_class_init(ObjectClass *oc, const void *data) > > hc->plug = virt_machine_device_plug_cb; > > hc->unplug_request = virt_machine_device_unplug_request_cb; > > hc->unplug = virt_machine_device_unplug_cb; > > + > > + mc->has_online_capable_cpus = true; > > + > > mc->nvdimm_supported = true; > > mc->smp_props.clusters_supported = true; > > mc->auto_enable_numa_with_memhp = true; > > diff --git a/include/hw/boards.h b/include/hw/boards.h > > index 2b182d7817..b27c2326a2 100644 > > --- a/include/hw/boards.h > > +++ b/include/hw/boards.h > > @@ -302,6 +302,7 @@ struct MachineClass { > > bool rom_file_has_mr; > > int minimum_page_bits; > > bool has_hotpluggable_cpus; > > + bool has_online_capable_cpus; > > bool ignore_memory_transaction_failures; > > int numa_mem_align_shift; > > const char * const *valid_cpu_types; > > -- > > 2.34.1 > > >

1 0

[PATCH] qemu: add support for dirty-sync-missed-zero-copy migration statistic
by Tejus GK 09 Oct '25

09 Oct '25

QEMU can report how many times a zerocopy send got deferred during a live migration with VIR_MIGRATE_ZEROCOPY enabled. Support the stat in libvirt as part of virDomainGetJobStats Signed-off-by: Tejus GK <tejus.gk(a)nutanix.com> --- include/libvirt/libvirt-domain.h | 9 +++++++++ src/qemu/qemu_domainjob.c | 6 ++++++ src/qemu/qemu_monitor.h | 1 + src/qemu/qemu_monitor_json.c | 2 ++ 4 files changed, 18 insertions(+) diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h index 71bb49fe6c..2959f692bb 100644 --- a/include/libvirt/libvirt-domain.h +++ b/include/libvirt/libvirt-domain.h @@ -5842,6 +5842,15 @@ typedef enum { */ # define VIR_DOMAIN_JOB_VFIO_DATA_TRANSFERRED "vfio_data_transferred" +/** + * VIR_DOMAIN_JOB_MEMORY_MISSED_ZERO_COPY: + * virDomainGetJobStats field: number of times zerocopy send failed + * during a live migration, as VIR_TYPED_PARAM_ULLONG. + * + * Since: 11.9.0 + */ +# define VIR_DOMAIN_JOB_MEMORY_MISSED_ZERO_COPY "memory_missed_zero_copy" + /** * virConnectDomainEventGenericCallback: * @conn: the connection pointer diff --git a/src/qemu/qemu_domainjob.c b/src/qemu/qemu_domainjob.c index afea1ea57a..61441888e9 100644 --- a/src/qemu/qemu_domainjob.c +++ b/src/qemu/qemu_domainjob.c @@ -420,6 +420,12 @@ qemuDomainMigrationJobDataToParams(virDomainJobData *jobData, stats->vfio_data_transferred) < 0) goto error; + if (stats->ram_missed_zero_copy && + virTypedParamsAddULLong(&par, &npar, &maxpar, + VIR_DOMAIN_JOB_MEMORY_MISSED_ZERO_COPY, + stats->ram_missed_zero_copy) < 0) + goto error; + done: *type = virDomainJobStatusToType(jobData->status); *params = par; diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h index 8ef85ceb0a..90e6efaf09 100644 --- a/src/qemu/qemu_monitor.h +++ b/src/qemu/qemu_monitor.h @@ -838,6 +838,7 @@ struct _qemuMonitorMigrationStats { unsigned long long ram_page_size; unsigned long long ram_iteration; unsigned long long ram_postcopy_reqs; + unsigned long long ram_missed_zero_copy; unsigned long long disk_transferred; unsigned long long disk_remaining; diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index 9caade7bc9..2b418d6cad 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -3129,6 +3129,8 @@ qemuMonitorJSONGetMigrationStatsReply(virJSONValue *reply, &stats->ram_iteration)); ignore_value(virJSONValueObjectGetNumberUlong(ram, "postcopy-requests", &stats->ram_postcopy_reqs)); + ignore_value(virJSONValueObjectGetNumberUlong(ram, "dirty-sync-missed-zero-copy", + &stats->ram_missed_zero_copy)); } disk = virJSONValueObjectGetObject(ret, "disk"); -- 2.43.7

1 1

[PATCH 0/1] Refine the domain status saving logic
by yong.huang＠smartx.com 09 Oct '25

09 Oct '25

From: Hyman Huang <yong.huang(a)smartx.com> When saving the domain status in the path of the virDomainObjSave function, Libvirtd will omit the private data if the format interface is not provided. When the Libvirtd service is starting up and the driver has not yet been initialized, this behavior is justified. However, when the service is shutting down, the driver is being finalized and the interface is being released, a migration job or another job may call the qemuDomainSaveStatus and save the domain status at the same time. For the latter, this behavior causes the XML to be saved without private information (such as monitor path and qemuCaps), which is required for the Libvirtd service to manage a VM during startup. As a result, after restarting the Libvirtd service, a running VM that is being migrated previously might escape management. Thus, when formatting the status XML for a running virtual machine, we need to presume that the "privateData.format" interface is present. Add a thorough check in the virDomainObjSave path to make sure that private data in the status XML file always exists for the running VM so that we won't lose it after restart the Libvirtd service. Please review, thanks. Yong Hyman Huang (1): domain_conf: Do not omit private data when formatting the status XML src/conf/domain_conf.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) -- 2.27.0

3 11

[PATCH] qemuDomainGetStatsCpuProc: Use string constants for CPU stats
by Peter Krempa 08 Oct '25

08 Oct '25

From: Peter Krempa <pkrempa(a)redhat.com> Commit 947306957e9 added the constants and fixed other uses but didn't fix qemuDomainGetStatsCpuProc. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_driver.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index ac72ea5cb0..d26c8997bf 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -17054,9 +17054,9 @@ qemuDomainGetStatsCpuProc(virDomainObj *vm, return; } - virTypedParamListAddULLong(params, cpuTime, "cpu.time"); - virTypedParamListAddULLong(params, userTime, "cpu.user"); - virTypedParamListAddULLong(params, sysTime, "cpu.system"); + virTypedParamListAddULLong(params, cpuTime, VIR_DOMAIN_STATS_CPU_TIME); + virTypedParamListAddULLong(params, userTime, VIR_DOMAIN_STATS_CPU_USER); + virTypedParamListAddULLong(params, sysTime, VIR_DOMAIN_STATS_CPU_SYSTEM); } -- 2.51.0

2 1

[PATCH] network: pf: split flush and rules commands
by Roman Bogorodskiy 08 Oct '25

08 Oct '25

Current implementation uses a single command to flush the old rules and create new ones. This is not optimal because if flush fails for some non-critical reasons (e.g. because the anchor didn't previously exist), it will block rules creation and network start. Split this command into two: one for flush, and one for rules creation. Also, don't fail if the flush command fails. Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- src/network/network_pf.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/src/network/network_pf.c b/src/network/network_pf.c index ce4461c999..a39eef5fa2 100644 --- a/src/network/network_pf.c +++ b/src/network/network_pf.c @@ -168,6 +168,7 @@ pfAddNatFirewallRules(virNetworkDef *def, g_autofree const char *forwardIf = g_strdup(virNetworkDefForwardIf(def, 0)); g_auto(virBuffer) pf_rules_buf = VIR_BUFFER_INITIALIZER; g_autoptr(virCommand) cmd = virCommandNew(PFCTL); + g_autoptr(virCommand) flush_cmd = virCommandNew(PFCTL); virPortRange *portRange = &def->forward.port; g_autofree char *portRangeStr = NULL; @@ -240,13 +241,25 @@ pfAddNatFirewallRules(virNetworkDef *def, "block on %s\n", def->bridge); - /* pfctl -a libvirt/default -F all -f - */ + /* pfctl -a libvirt/default -f - */ virCommandAddArg(cmd, "-a"); virCommandAddArgFormat(cmd, "libvirt/%s", def->name); - virCommandAddArgList(cmd, "-F", "all", "-f", "-", NULL); + virCommandAddArgList(cmd, "-f", "-", NULL); virCommandSetInputBuffer(cmd, virBufferContentAndReset(&pf_rules_buf)); + /* pfctl -a libvirt/default -F all */ + /* Flush rules as a separate command, so when it fails, e.g. because the + * anchor didn't exist, we still proceed with rules creation */ + virCommandAddArg(flush_cmd, "-a"); + virCommandAddArgFormat(flush_cmd, "libvirt/%s", def->name); + virCommandAddArgList(flush_cmd, "-F", "all", NULL); + + if (virCommandRun(flush_cmd, NULL) < 0) { + VIR_WARN("Failed to flush firewall rules for network %s", + def->name); + } + if (virCommandRun(cmd, NULL) < 0) { VIR_WARN("Failed to create firewall rules for network %s", def->name); -- 2.51.0

2 1

[RFC] Secure IPL For S390X Guests: Domain XML Draft
by Zhuoying Cai 07 Oct '25

07 Oct '25

Hi, I have been working on support for Secure IPL on s390x in QEMU, which includes signature verification and other security checks to ensure system integrity. For more context, here is the latest patch series: https://lists.gnu.org/archive/html/qemu-s390x/2025-09/msg00136.html Since Secure IPL on s390x is supported in QEMU, I would like to begin drafting the corresponding Libvirt interface and seek feedback before proceeding with the implementation. New parameters have been added to the s390-ccw-virtio machine type to enable Secure IPL and provide certificates for signature verification. This parameter enables or disables Secure IPL/boot. If not specified, it defaults to off. (https://lists.gnu.org/archive/html/qemu-s390x/2025-09/msg00150.html) qemu-system-s390x -machine s390-ccw-virtio,secure-boot=on|off This parameter specifies one or more paths to boot certificates, used for signature verification. You can provide a single certificate file or a directory. (https://lists.gnu.org/archive/html/qemu-s390x/2025-09/msg00138.html) qemu-system-s390x -machine s390-ccw-virtio, \ boot-certs.0.path=/.../qemu/certs, \ boot-certs.1.path=/another/path/cert.pem While Libvirt already provides a secure boot interface (https://libvirt.org/kbase/secureboot.html) it appears to be primarily intended for x86 systems, where secure boot is configured using the <firmware>, <loader>, and <nvram> tags. <os firmware='efi'> <firmware> <feature enabled='yes' name='enrolled-keys'/> <feature enabled='yes' name='secure-boot'/> </firmware> <loader secure='yes' type='pflash'>...</loader> <nvram template='...'>...</nvram> </os> For s390x, some of these existing tags may be reused, but additional elements will be needed. Below is my initial proposal for the secure boot interface in Libvirt:  <os firmware='s390-ccw-bios'> <type arch='s390x' machine='s390-ccw-virtio-9.2'>hvm</type> <firmware>  <feature enabled='yes' name='secure-boot'/> </firmware>  <boot-certs path='/path/to/cert.pem' /> <boot-certs path='/path/to/cert-dir' /> <boot dev='hd'/> </os> Below is an example of the corresponding QEMU command line: qemu-system-s390x -machine s390-ccw-virtio, secure-boot=on, \ boot-certs.0.path=/path/to/cert.pem, \ boot-certs.1.path=/path/to/cert-dir ... I would be greatly appreciate any suggestions or feedback on this proposal, and I am open to refining the design to better align with existing Libvirt structures. Best regards, Joy

1 0

[PATCH 0/2] Forbid 'g_new' (the one without clearing memory)
by Peter Krempa 07 Oct '25

07 Oct '25

I got burned by it in WIP patches. Let's not allow it anywhere. Peter Krempa (2): Replace all use of 'g_new' with 'g_new0' syntax-check: Prohibit the non-clearing 'g_new' build-aux/syntax-check.mk | 2 +- src/network/network_pf.c | 2 +- src/qemu/qemu_nbdkit.c | 2 +- src/qemu/qemu_process.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) -- 2.51.0

2 3

[PATCH] qemu-replies-tool: Fix logic error when dumping device properties
by Peter Krempa 07 Oct '25

07 Oct '25

From: Peter Krempa <pkrempa(a)redhat.com> In a recent refactor the block of code outputting device properties was mis-indented causing it to only work on device properties which have no 'default-value'. Fixes: 301e1ba244f Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- scripts/qemu-replies-tool.py | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/scripts/qemu-replies-tool.py b/scripts/qemu-replies-tool.py index cf99ecd1f3..21401452cf 100755 --- a/scripts/qemu-replies-tool.py +++ b/scripts/qemu-replies-tool.py @@ -436,16 +436,16 @@ def dump_device_and_object_properties(conv, dumpprefix): if k not in ['name', 'type', 'description', 'default-value']: raise Exception("Unhandled 'device-list-properties'/'qom-list-properties' typename '%s' field '%s'" % (c['cmd']['arguments']['typename'], k)) - if 'default-value' in arg: - defval = ' (%s)' % str(arg['default-value']) - else: - defval = '' - - ent.append('%s %s %s %s%s' % (prefix, - c['cmd']['arguments']['typename'], - arg['name'], - arg['type'], - defval)) + if 'default-value' in arg: + defval = ' (%s)' % str(arg['default-value']) + else: + defval = '' + + ent.append('%s %s %s %s%s' % (prefix, + c['cmd']['arguments']['typename'], + arg['name'], + arg['type'], + defval)) ent.sort() for e in ent: -- 2.51.0

2 1