- Devel - libvirt List Archives

[PATCH v2] virsh: Introduce new hypervisor-cpu-models command
by Collin Walling 20 Mar '25

20 Mar '25

From: David Judkovics <djudkovi(a)linux.ibm.com> Add new virsh command 'hypervisor-cpu-models'. Command pulls from the existing domcapabilities XML and uses xpath to parse CPU model strings. By default, only models reported as usable by the hypervisor on the host system are printed. User may specify "--all" to also print models which are not supported on the host. Signed-off-by: David Judkovics <djudkovi(a)linux.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com> Signed-off-by: Collin Walling <walling(a)linux.ibm.com> Reviewed-by: Ján Tomko <jtomko(a)redhat.com> --- Changelog: v2 - Corrected virsh.rst documentation - Removed unwanted_positional from emulator option - Adjusted xpath string based on feedback --- docs/manpages/virsh.rst | 25 ++++++++++++++ tools/virsh-host.c | 75 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 100 insertions(+) diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst index baced15dec..612c567ff4 100644 --- a/docs/manpages/virsh.rst +++ b/docs/manpages/virsh.rst @@ -1034,6 +1034,31 @@ listed in the XML description. If *--migratable* is specified, features that block migration will not be included in the resulting CPU. +hypervisor-cpu-models +--------------------- + +**Syntax:** + +:: + + hypervisor-cpu-models [--virttype virttype] [--emulator emulator] + [--arch arch] [--machine machine] [--all] + +Print the list of CPU models known by the hypervisor for the specified architecture. +It is not guaranteed that a listed CPU will run on the host. To determine CPU +model compatibility with the host, see ``virsh hypervisor-cpu-baseline`` and +``virsh hypervisor-cpu-compare``. + +The *virttype* option specifies the virtualization type (usable in the 'type' +attribute of the <domain> top level element from the domain XML). *emulator* +specifies the path to the emulator, *arch* specifies the CPU architecture, and +*machine* specifies the machine type. + +By default, only the models that are claimed to be "usable" by the hypervisor +on the host are reported. The option *--all* will report every CPU model known +to the hypervisor, including ones that are not supported on the hypervisor (e.g. +newer generation models). + DOMAIN COMMANDS =============== diff --git a/tools/virsh-host.c b/tools/virsh-host.c index 9e8f542c96..f4e34fb146 100644 --- a/tools/virsh-host.c +++ b/tools/virsh-host.c @@ -1766,6 +1766,75 @@ cmdHypervisorCPUBaseline(vshControl *ctl, } +/* + * "hypervisor-cpu-models" command + */ +static const vshCmdInfo info_hypervisor_cpu_models = { + .help = N_("Hypervisor reported CPU models"), + .desc = N_("Get the CPU models reported by the hypervisor."), +}; + +static const vshCmdOptDef opts_hypervisor_cpu_models[] = { + {.name = "virttype", + .type = VSH_OT_STRING, + .completer = virshDomainVirtTypeCompleter, + .help = N_("virtualization type (/domain/@type)"), + }, + {.name = "emulator", + .type = VSH_OT_STRING, + .help = N_("path to emulator binary (/domain/devices/emulator)"), + }, + {.name = "arch", + .type = VSH_OT_STRING, + .completer = virshArchCompleter, + .help = N_("CPU architecture (/domain/os/type/@arch)"), + }, + {.name = "machine", + .type = VSH_OT_STRING, + .help = N_("machine type (/domain/os/type/@machine)"), + }, + {.name = "all", + .type = VSH_OT_BOOL, + .help = N_("include all CPU models known to the hypervisor for the architecture") + }, + {.name = NULL} +}; + +static bool +cmdHypervisorCPUModelNames(vshControl *ctl, + const vshCmd *cmd) +{ + g_autofree char *caps_xml = NULL; + const char *virttype = NULL; + const char *emulator = NULL; + const char *arch = NULL; + const char *machine = NULL; + const char *xpath = NULL; + virshControl *priv = ctl->privData; + + if (vshCommandOptString(ctl, cmd, "virttype", &virttype) < 0 || + vshCommandOptString(ctl, cmd, "emulator", &emulator) < 0 || + vshCommandOptString(ctl, cmd, "arch", &arch) < 0 || + vshCommandOptString(ctl, cmd, "machine", &machine) < 0) + return false; + + if (vshCommandOptBool(cmd, "all")) + xpath = "//cpu//model[@usable]/text()"; + else + xpath = "//cpu//model[@usable='yes']/text()"; + + caps_xml = virConnectGetDomainCapabilities(priv->conn, emulator, arch, + machine, virttype, 0); + + if (!caps_xml) { + vshError(ctl, "%s", _("failed to get hypervisor CPU model names")); + return false; + } + + return virshDumpXML(ctl, caps_xml, "domcapabilities", xpath, false); +} + + const vshCmdDef hostAndHypervisorCmds[] = { {.name = "allocpages", .handler = cmdAllocpages, @@ -1833,6 +1902,12 @@ const vshCmdDef hostAndHypervisorCmds[] = { .info = &info_hypervisor_cpu_compare, .flags = 0 }, + {.name = "hypervisor-cpu-models", + .handler = cmdHypervisorCPUModelNames, + .opts = opts_hypervisor_cpu_models, + .info = &info_hypervisor_cpu_models, + .flags = 0 + }, {.name = "maxvcpus", .handler = cmdMaxvcpus, .opts = opts_maxvcpus, -- 2.47.1

2 1

Questions regarding potential resize implementation in libvirt
by Maximilian Immanuel Brandtner 20 Mar '25

20 Mar '25

I've been working on an RFC patch-set to implement resizing for consoles in QEMU. Now that the patch-set is in review I've turned my attention to bringing this feature to libvirt. With the QEMU patch-set there are two ways to resize a pty chardev. 1. send a TIOCSWINSZ ioctl 2. send a QMP msg The first approach doesn't work under Libvirt. Pty chardevs are proxied over a FIFO meaning the ioctl wouldn't get to libvirt. Furthermore, this approach is incompatible with remote management which libvirt seems to go to great lengths to support. Sending a QMP message is a QEMU specific feature. It seems to me that adding a new handle (something like domainResizeConsole) would have to be added to the virHypervisorDriver struct. It would be really nifty if the resize handle could be implemented in the virStream, however it seems that all the virStreamDriver handlers are common code (aka shared across all hypervisors). From what I've seen it seems that the only way to switch from common code to hypervisor specific code would be over the virHypervisorDriver. As it stands it seems to me that the best course of action would be adding a new handle to the virHypervisorDriver, but I'm unsure whether that's really the right call. Furthermore, if we don't want to broadcast a QMP message to every chardev, the handle needs to determine the alias with which the chardev can be adressed in QMP. in qemuDomainOpenConsole the alias for the console is set and added as the callback argument for the internal close function. There doesn't seem to be a way to get the alias of a console from virStream. It seems that I need to add an alias string field to the virStream or the virStreamFDData. I could however be mistaken and there is already a way to get the alias for a virStream, hence this email TLDR I have the following 2 questions: - Should the resize handle be implemented in the virHypervisorDriver directly or in the virStreamDriver? - Is there a way to get the QMP alias of a chardev from a virStream? Thanks in advance Max

3 7

[PATCH] virsh: Introduce new hypervisor-cpu-models command
by Collin Walling 20 Mar '25

20 Mar '25

From: David Judkovics <djudkovi(a)linux.ibm.com> Add new virsh command 'hypervisor-cpu-models'. Command pulls from the existing domcapabilities XML and uses xpath to parse CPU model strings. By default, only models reported as usable by the hypervisor on the host system are printed. User may specify "--all" to also print models which are not supported on the host. Signed-off-by: David Judkovics <djudkovi(a)linux.ibm.com> Signed-off-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com> Signed-off-by: Collin Walling <walling(a)linux.ibm.com> --- This is a continuation of a previous series found here: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/I4Y… --- docs/manpages/virsh.rst | 24 +++++++++++++ tools/virsh-host.c | 74 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 98 insertions(+) diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst index baced15dec..48b667736d 100644 --- a/docs/manpages/virsh.rst +++ b/docs/manpages/virsh.rst @@ -1034,6 +1034,30 @@ listed in the XML description. If *--migratable* is specified, features that block migration will not be included in the resulting CPU. +hypervisor-cpu-models +--------------------- + +**Syntax:** + +:: + + hypervisor-cpu-models [virttype] [emulator] [arch] [machine] [--all] + +Print the list of CPU models known by the hypervisor for the specified architecture. +It is not guaranteed that a listed CPU will run on the host. To determine CPU +model compatibility with the host, see ``virsh hypervisor-cpu-baseline`` and +``virsh hypervisor-cpu-compare``. + +The *virttype* option specifies the virtualization type (usable in the 'type' +attribute of the <domain> top level element from the domain XML). *emulator* +specifies the path to the emulator, *arch* specifies the CPU architecture, and +*machine* specifies the machine type. + +By default, only the models that are claimed to be "usable" by the hypervisor +on the host are reported. The option *--all* will report every CPU model known +to the hypervisor, including ones that are not supported on the hypervisor (e.g. +newer generation models). + DOMAIN COMMANDS =============== diff --git a/tools/virsh-host.c b/tools/virsh-host.c index 9e8f542c96..2884067bbb 100644 --- a/tools/virsh-host.c +++ b/tools/virsh-host.c @@ -1766,6 +1766,74 @@ cmdHypervisorCPUBaseline(vshControl *ctl, } +/* + * "hypervisor-cpu-models" command + */ +static const vshCmdInfo info_hypervisor_cpu_models = { + .help = N_("Hypervisor reported CPU models"), + .desc = N_("Get the CPU models reported by the hypervisor."), +}; + +static const vshCmdOptDef opts_hypervisor_cpu_models[] = { + {.name = "virttype", + .type = VSH_OT_STRING, + .completer = virshDomainVirtTypeCompleter, + .help = N_("virtualization type (/domain/@type)"), + }, + {.name = "emulator", + .type = VSH_OT_STRING, + .unwanted_positional = true, + .help = N_("path to emulator binary (/domain/devices/emulator)"), + }, + {.name = "arch", + .type = VSH_OT_STRING, + .completer = virshArchCompleter, + .help = N_("CPU architecture (/domain/os/type/@arch)"), + }, + {.name = "machine", + .type = VSH_OT_STRING, + .help = N_("machine type (/domain/os/type/@machine)"), + }, + {.name = "all", + .type = VSH_OT_BOOL, + .help = N_("include all CPU models known to the hypervisor for the architecture") + }, + {.name = NULL} +}; + +static bool +cmdHypervisorCPUModelNames(vshControl *ctl, + const vshCmd *cmd) +{ + g_autofree char *caps_xml = NULL; + const char *virttype = NULL; + const char *emulator = NULL; + const char *arch = NULL; + const char *machine = NULL; + const char *xpath_all = "//cpu//model[@usable]/text()"; + const char *xpath_usable = "//cpu//model[@usable='yes']/text()"; + virshControl *priv = ctl->privData; + + if (vshCommandOptString(ctl, cmd, "virttype", &virttype) < 0 || + vshCommandOptString(ctl, cmd, "emulator", &emulator) < 0 || + vshCommandOptString(ctl, cmd, "arch", &arch) < 0 || + vshCommandOptString(ctl, cmd, "machine", &machine) < 0) + return false; + + caps_xml = virConnectGetDomainCapabilities(priv->conn, emulator, arch, + machine, virttype, 0); + + if (!caps_xml) { + vshError(ctl, "%s", _("failed to get hypervisor CPU model names")); + return false; + } + + return virshDumpXML(ctl, caps_xml, "domcapabilities", + vshCommandOptBool(cmd, "all") ? xpath_all : xpath_usable, + false); +} + + const vshCmdDef hostAndHypervisorCmds[] = { {.name = "allocpages", .handler = cmdAllocpages, @@ -1833,6 +1901,12 @@ const vshCmdDef hostAndHypervisorCmds[] = { .info = &info_hypervisor_cpu_compare, .flags = 0 }, + {.name = "hypervisor-cpu-models", + .handler = cmdHypervisorCPUModelNames, + .opts = opts_hypervisor_cpu_models, + .info = &info_hypervisor_cpu_models, + .flags = 0 + }, {.name = "maxvcpus", .handler = cmdMaxvcpus, .opts = opts_maxvcpus, -- 2.47.1

3 6

[PATCH 0/5] qemu: Two block job fixes
by Peter Krempa 19 Mar '25

19 Mar '25

Peter Krempa (5): qemu: monitor: Wire up 'replaces' attribute for 'blockdev-mirror' qemu: Do not replace filter nodes with virDomainBlockCopy qemu: Remove return value from 'qemuHotplugRemoveManagedPR' qemuDomainChangeEjectableMedia: Separate rollback and success code paths qemuHotplugRemoveManagedPR: Integrate check whether removal is needed src/qemu/qemu_blockjob.c | 2 +- src/qemu/qemu_driver.c | 3 +- src/qemu/qemu_hotplug.c | 58 +++++++++++++++--------------------- src/qemu/qemu_hotplug.h | 3 +- src/qemu/qemu_migration.c | 1 + src/qemu/qemu_monitor.c | 9 +++--- src/qemu/qemu_monitor.h | 1 + src/qemu/qemu_monitor_json.c | 2 ++ src/qemu/qemu_monitor_json.h | 1 + tests/qemumonitorjsontest.c | 2 +- 10 files changed, 40 insertions(+), 42 deletions(-) -- 2.48.1

2 6

[libvirt PATCH 0/7] qemu: introduce amd-iommu support
by Ján Tomko 19 Mar '25

19 Mar '25

To the cc'd QEMU developers - I'd appreciate guidance on how/whether to document and expose the 'xtsup' and 'pt' parameters to libvirt users. Based on QEMU series: Subject: [PATCH v4 0/2] hw/i386/amd_iommu: Add migration support From: Suravee Suthikulpanit <suravee.suthikulpanit(a)amd.com> Message-ID: <20250304141716.638880-1-suravee.suthikulpanit(a)amd.com> (not yet merged in upstream QEMU) Ján Tomko (7): qemu: introduce QEMU_CAPS_AMD_IOMMU qemu: introduce QEMU_CAPS_PCI_ID qemu: add IOMMU model amd docs: formatdomain: document intel-only IOMMU attributes conf: add passthrough and xtsup attributes for IOMMU conf: reject some attributes not applicable to intel IOMMU qemu: format pt and xstup on the command line docs/formatdomain.rst | 22 +++- src/conf/domain_conf.c | 31 +++++ src/conf/domain_conf.h | 3 + src/conf/domain_validate.c | 22 ++++ src/conf/schemas/domaincommon.rng | 11 ++ src/qemu/qemu_capabilities.c | 12 ++ src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_command.c | 30 +++++ src/qemu/qemu_domain_address.c | 4 + src/qemu/qemu_validate.c | 29 +++++ .../caps_10.0.0_x86_64+amdsev.replies | 102 +++++++++++------ .../caps_10.0.0_x86_64+amdsev.xml | 1 + .../caps_10.0.0_x86_64.replies | 106 ++++++++++++------ .../caps_10.0.0_x86_64.xml | 2 + .../caps_6.2.0_x86_64.replies | 102 +++++++++++------ .../caps_6.2.0_x86_64.xml | 1 + .../caps_7.0.0_x86_64.replies | 80 +++++++------ .../caps_7.0.0_x86_64.xml | 1 + .../caps_7.1.0_x86_64.replies | 102 +++++++++++------ .../caps_7.1.0_x86_64.xml | 1 + .../caps_7.2.0_x86_64+hvf.replies | 102 +++++++++++------ .../caps_7.2.0_x86_64+hvf.xml | 1 + .../caps_7.2.0_x86_64.replies | 102 +++++++++++------ .../caps_7.2.0_x86_64.xml | 1 + .../caps_8.0.0_x86_64.replies | 80 +++++++------ .../caps_8.0.0_x86_64.xml | 1 + .../caps_8.1.0_x86_64.replies | 102 +++++++++++------ .../caps_8.1.0_x86_64.xml | 1 + .../caps_8.2.0_x86_64.replies | 102 +++++++++++------ .../caps_8.2.0_x86_64.xml | 1 + .../caps_9.0.0_x86_64.replies | 80 +++++++------ .../caps_9.0.0_x86_64.xml | 1 + .../caps_9.1.0_x86_64.replies | 102 +++++++++++------ .../caps_9.1.0_x86_64.xml | 1 + .../caps_9.2.0_x86_64+amdsev.replies | 102 +++++++++++------ .../caps_9.2.0_x86_64+amdsev.xml | 1 + .../caps_9.2.0_x86_64.replies | 102 +++++++++++------ .../caps_9.2.0_x86_64.xml | 1 + .../amd-iommu.x86_64-latest.args | 35 ++++++ .../amd-iommu.x86_64-latest.xml | 1 + tests/qemuxmlconfdata/amd-iommu.xml | 39 +++++++ tests/qemuxmlconftest.c | 2 + 42 files changed, 1172 insertions(+), 454 deletions(-) create mode 100644 tests/qemuxmlconfdata/amd-iommu.x86_64-latest.args create mode 120000 tests/qemuxmlconfdata/amd-iommu.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/amd-iommu.xml -- 2.48.1

1 8

[PATCH 0/6] qemu: Add support for iothread to virtqueue mapping for 'virtio-scsi'
by Peter Krempa 19 Mar '25

19 Mar '25

The qemu part was now merged. Diff to rfc-v2: - The 'ctrl' and 'event' queues are not exposed to be mapped: - dropped patch for named queue support - adapted validation logic - adapted docs Peter Krempa (6): qemucapabilitiestest: Update 'caps_10.0.0_x86_64' to v9.2.0-2799-g0462a32b4f qemu: capabilities: Introduce QEMU_CAPS_VIRTIO_SCSI_IOTHREAD_MAPPING conf: Add support for iothread to queue mapping config for 'virtio-scsi' qemu: Implement support for iothread <-> virtqueue mapping for 'virtio-scsi' controllers qemuxmlconftest: Add 'iothreads-virtio-scsi-mapping' case NEWS: Mention multiple iothread support for 'virtio-scsi' controller NEWS.rst | 6 + docs/formatdomain.rst | 39 ++++ src/conf/domain_conf.c | 10 +- src/conf/domain_conf.h | 1 + src/conf/domain_validate.c | 10 +- src/conf/schemas/domaincommon.rng | 3 + src/hypervisor/domain_driver.c | 3 +- src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_command.c | 6 + src/qemu/qemu_validate.c | 30 ++- .../caps_10.0.0_x86_64.replies | 193 ++++++++++-------- .../caps_10.0.0_x86_64.xml | 7 +- ...ads-virtio-scsi-mapping.x86_64-latest.args | 40 ++++ ...eads-virtio-scsi-mapping.x86_64-latest.xml | 61 ++++++ .../iothreads-virtio-scsi-mapping.xml | 53 +++++ tests/qemuxmlconftest.c | 1 + 17 files changed, 369 insertions(+), 101 deletions(-) create mode 100644 tests/qemuxmlconfdata/iothreads-virtio-scsi-mapping.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/iothreads-virtio-scsi-mapping.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/iothreads-virtio-scsi-mapping.xml -- 2.48.1

2 7

[PATCH v2 0/3] Reflect MAC change in live domain XML
by Michal Privoznik 18 Mar '25

18 Mar '25

v2 of https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/AVMO… diff to v1: - If the MAC address is changed to its original the proper event is emitted. - In 3/3 some variables were renamed to avoid ambiguity. Michal Prívozník (3): qemu: Reflect MAC address change in live domain XML Introduce NIC_MAC_CHANGE event qemu: Emit NIC_MAC_CHANGE event docs/formatdomain.rst | 5 ++ examples/c/misc/event-test.c | 14 +++++ include/libvirt/libvirt-domain.h | 28 +++++++++ src/conf/domain_conf.c | 6 ++ src/conf/domain_conf.h | 3 + src/conf/domain_event.c | 93 +++++++++++++++++++++++++++++ src/conf/domain_event.h | 12 ++++ src/conf/schemas/domaincommon.rng | 5 ++ src/libvirt_private.syms | 2 + src/qemu/qemu_domain.c | 48 ++++++++++++++- src/qemu/qemu_domain.h | 3 +- src/qemu/qemu_driver.c | 11 ++-- src/qemu/qemu_process.c | 2 +- src/remote/remote_daemon_dispatch.c | 32 ++++++++++ src/remote/remote_driver.c | 34 +++++++++++ src/remote/remote_protocol.x | 17 +++++- src/remote_protocol-structs | 8 +++ tools/virsh-domain-event.c | 20 +++++++ 18 files changed, 335 insertions(+), 8 deletions(-) -- 2.48.1

3 7

[libvirt PATCH] conf: also free auth for rdp in virDomainGraphicsDefFree
by Ján Tomko 18 Mar '25

18 Mar '25

Signed-off-by: Ján Tomko <jtomko(a)redhat.com> Fixes: bfa7d5aaa8834c6801cacbfc6c6ea83a8ecaca9c --- Pushed as a trivial CI fix src/conf/domain_conf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 5748a89bd1..d05e68dd41 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -2032,6 +2032,7 @@ void virDomainGraphicsDefFree(virDomainGraphicsDef *def) break; case VIR_DOMAIN_GRAPHICS_TYPE_RDP: + virDomainGraphicsAuthDefClear(&def->data.rdp.auth); break; case VIR_DOMAIN_GRAPHICS_TYPE_DESKTOP: -- 2.48.1

1 0

[libvirt PATCH] qemu: remove unreachable breaks in qemuDomainAssignMemoryDeviceSlot
by Ján Tomko 18 Mar '25

18 Mar '25

Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- Pushed as trivial src/qemu/qemu_domain_address.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c index 5b94c27679..e89cdee487 100644 --- a/src/qemu/qemu_domain_address.c +++ b/src/qemu/qemu_domain_address.c @@ -3077,12 +3077,10 @@ qemuDomainAssignMemoryDeviceSlot(virDomainObj *vm, return -1; return qemuAssignMemoryDeviceSlot(mem, slotmap); - break; case VIR_DOMAIN_MEMORY_MODEL_VIRTIO_PMEM: case VIR_DOMAIN_MEMORY_MODEL_VIRTIO_MEM: return qemuDomainEnsureVirtioAddress(&releaseaddr, vm, &dev); - break; case VIR_DOMAIN_MEMORY_MODEL_SGX_EPC: case VIR_DOMAIN_MEMORY_MODEL_NONE: -- 2.48.1

1 0

[PATCH v2] qemu_domain_address: fix CCW virtio-mem hotplug
by Boris Fiuczynski 18 Mar '25

18 Mar '25

Since commit f23f8ff91a virtio-mem supports also CCW. When hotplugging a virtio-mem device with a CCW address results in a PCI device getting attached. The method qemuDomainAssignMemoryDeviceSlot is only considering PCI as address type and overwriting the CCW address. Adding support for address type CCW. Signed-off-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com> --- src/qemu/qemu_domain_address.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c index d38983bf63..5b94c27679 100644 --- a/src/qemu/qemu_domain_address.c +++ b/src/qemu/qemu_domain_address.c @@ -3067,6 +3067,7 @@ qemuDomainAssignMemoryDeviceSlot(virDomainObj *vm, virDomainMemoryDef *mem) { g_autoptr(virBitmap) slotmap = NULL; + bool releaseaddr = false; virDomainDeviceDef dev = {.type = VIR_DOMAIN_DEVICE_MEMORY, .data.memory = mem}; switch (mem->model) { @@ -3080,7 +3081,7 @@ qemuDomainAssignMemoryDeviceSlot(virDomainObj *vm, case VIR_DOMAIN_MEMORY_MODEL_VIRTIO_PMEM: case VIR_DOMAIN_MEMORY_MODEL_VIRTIO_MEM: - return qemuDomainEnsurePCIAddress(vm, &dev); + return qemuDomainEnsureVirtioAddress(&releaseaddr, vm, &dev); break; case VIR_DOMAIN_MEMORY_MODEL_SGX_EPC: -- 2.47.0

2 1