12:55 p.m.
v2 of:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/KA...
diff to v1:
- Previously, virtio-mem-pci wasn't supported (in fact QEMU errored
out), but this changed in QEMU upstream, so this limitation is lifted.
- Added a test case for virtio-mem-pci on s390x
Most of the patches is ACKed already (thanks Boris and David!), only a
few remain for review.
Michal Prívozník (8):
qemu: Do NOT autoadd NUMA node for s390
qemu_command: Use qemuBuildVirtioDevProps() to build cmd line for
virtio-mem and virtio-pmem
qemuxmlconftest: Introduce memory-hotplug-virtio-mem-pci-s390x.xml
qemu_caps: Introduce QEMU_CAPS_DEVICE_VIRTIO_MEM_CCW
qemu: Validate virtio-mem-ccw
qemu: Allow virtio-mem on CCW
qemuxmlconftest: Introduce memory-hotplug-virtio-mem-ccw-s390x.xml
NEWS: Document virtio-mem-ccw
NEWS.rst | 5 ++
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 28 ++++++--
src/qemu/qemu_domain.c | 6 +-
src/qemu/qemu_postparse.c | 1 +
src/qemu/qemu_validate.c | 35 ++++++++-
.../caps_10.0.0_s390x.xml | 1 +
...lug-virtio-mem-ccw-s390x.s390x-latest.args | 39 ++++++++++
...plug-virtio-mem-ccw-s390x.s390x-latest.xml | 60 ++++++++++++++++
.../memory-hotplug-virtio-mem-ccw-s390x.xml | 57 +++++++++++++++
...lug-virtio-mem-pci-s390x.s390x-latest.args | 41 +++++++++++
...plug-virtio-mem-pci-s390x.s390x-latest.xml | 71 +++++++++++++++++++
.../memory-hotplug-virtio-mem-pci-s390x.xml | 59 +++++++++++++++
tests/qemuxmlconftest.c | 2 +
15 files changed, 399 insertions(+), 9 deletions(-)
create mode 100644
tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.s390x-latest.args
create mode 100644
tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.s390x-latest.xml
create mode 100644 tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.xml
create mode 100644
tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.s390x-latest.args
create mode 100644
tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.s390x-latest.xml
create mode 100644 tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.xml
--
2.45.3
12:55 p.m.
New subject: [PATCH v2 1/8] qemu: Do NOT autoadd NUMA node for s390
In some cases, we might automatically add a NUMA node. But this
doesn't work for s390 really, because in its commit
v2.12.0-rc0~41^2~6 QEMU forbade specifying NUMA nodes for s390.
Suppress automatic adding of NUMA node on our side.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
Reviewed-by: David Hildenbrand <david(a)redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com>
---
src/qemu/qemu_domain.c | 3 ++-
src/qemu/qemu_postparse.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index c7d7ac26ce..6554b992f0 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -7761,7 +7761,8 @@ qemuDomainDefValidateMemoryHotplug(const virDomainDef *def,
return 0;
}
- if (!ARCH_IS_PPC64(def->os.arch)) {
+ if (!ARCH_IS_PPC64(def->os.arch) &&
+ !ARCH_IS_S390(def->os.arch)) {
/* due to guest support, qemu would silently enable NUMA with one node
* once the memory hotplug backend is enabled. To avoid possible
* confusion we will enforce user originated numa configuration along
diff --git a/src/qemu/qemu_postparse.c b/src/qemu/qemu_postparse.c
index 1f9077982a..20ee333e0d 100644
--- a/src/qemu/qemu_postparse.c
+++ b/src/qemu/qemu_postparse.c
@@ -1805,6 +1805,7 @@ qemuDomainDefNumaAutoAdd(virDomainDef *def,
if (!abiUpdate ||
!virDomainDefHasMemoryHotplug(def) ||
+ qemuDomainIsS390CCW(def) ||
virDomainNumaGetNodeCount(def->numa) > 0) {
return 0;
}
--
2.45.3
12:55 p.m.
New subject: [PATCH v2 2/8] qemu_command: Use qemuBuildVirtioDevProps() to build cmd line for virtio-mem and virtio-pmem
Both, virtio-mem and virtio-pmem devices follow traditional QEMU
naming convention: their suffix determines what bus they live on.
For instance, virtio-mem-pci, virtio-mem-ccw, virtio-pmem-pci.
We already have a function that constructs device name following
this convention: qemuBuildVirtioDevGetConfigDev().
While there's no virtio-pmem-ccw device yet, the function can
still be used.
Another advantage of using the function is - it'll be easier in
future when we want to configure various virtio aspects of memory
devices (like ats, iommu_platform, etc.).
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com>
---
src/qemu/qemu_command.c | 28 ++++++++++++++++++++++++----
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 9e96c59bad..7370711918 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -959,6 +959,23 @@ qemuBuildVirtioDevGetConfigDev(const virDomainDeviceDef *device,
break;
}
+ case VIR_DOMAIN_DEVICE_MEMORY:
+ switch (device->data.memory->model) {
+ case VIR_DOMAIN_MEMORY_MODEL_VIRTIO_PMEM:
+ *baseName = "virtio-pmem";
+ break;
+ case VIR_DOMAIN_MEMORY_MODEL_VIRTIO_MEM:
+ *baseName = "virtio-mem";
+ break;
+ case VIR_DOMAIN_MEMORY_MODEL_DIMM:
+ case VIR_DOMAIN_MEMORY_MODEL_NVDIMM:
+ case VIR_DOMAIN_MEMORY_MODEL_SGX_EPC:
+ case VIR_DOMAIN_MEMORY_MODEL_NONE:
+ case VIR_DOMAIN_MEMORY_MODEL_LAST:
+ break;
+ }
+ break;
+
case VIR_DOMAIN_DEVICE_LEASE:
case VIR_DOMAIN_DEVICE_WATCHDOG:
case VIR_DOMAIN_DEVICE_GRAPHICS:
@@ -971,7 +988,6 @@ qemuBuildVirtioDevGetConfigDev(const virDomainDeviceDef *device,
case VIR_DOMAIN_DEVICE_SHMEM:
case VIR_DOMAIN_DEVICE_TPM:
case VIR_DOMAIN_DEVICE_PANIC:
- case VIR_DOMAIN_DEVICE_MEMORY:
case VIR_DOMAIN_DEVICE_IOMMU:
case VIR_DOMAIN_DEVICE_AUDIO:
case VIR_DOMAIN_DEVICE_PSTORE:
@@ -3486,12 +3502,16 @@ qemuBuildMemoryDeviceProps(virQEMUDriverConfig *cfg,
break;
case VIR_DOMAIN_MEMORY_MODEL_VIRTIO_PMEM:
- device = "virtio-pmem-pci";
+ /* Deliberately not setting @device. */
+ if (!(props = qemuBuildVirtioDevProps(VIR_DOMAIN_DEVICE_MEMORY, mem,
priv->qemuCaps)))
+ return NULL;
address = mem->target.virtio_pmem.address;
break;
case VIR_DOMAIN_MEMORY_MODEL_VIRTIO_MEM:
- device = "virtio-mem-pci";
+ /* Deliberately not setting @device. */
+ if (!(props = qemuBuildVirtioDevProps(VIR_DOMAIN_DEVICE_MEMORY, mem,
priv->qemuCaps)))
+ return NULL;
if (virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI_PREALLOC)
&&
qemuBuildMemoryGetPagesize(cfg, def, mem, NULL, NULL, NULL, &prealloc)
< 0)
@@ -3513,7 +3533,7 @@ qemuBuildMemoryDeviceProps(virQEMUDriverConfig *cfg,
}
if (virJSONValueObjectAdd(&props,
- "s:driver", device,
+ "S:driver", device,
"k:node", mem->targetNode,
"P:label-size", labelsize * 1024,
"P:block-size", blocksize * 1024,
--
2.45.3
12:55 p.m.
New subject: [PATCH v2 3/8] qemuxmlconftest: Introduce memory-hotplug-virtio-mem-pci-s390x.xml
As of v9.2.0-1413-gd77ae821e8 QEMU supports virtio-mem-pci on
s390 too. Let's add a test case for that.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
...lug-virtio-mem-pci-s390x.s390x-latest.args | 41 +++++++++++
...plug-virtio-mem-pci-s390x.s390x-latest.xml | 71 +++++++++++++++++++
.../memory-hotplug-virtio-mem-pci-s390x.xml | 59 +++++++++++++++
tests/qemuxmlconftest.c | 1 +
4 files changed, 172 insertions(+)
create mode 100644
tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.s390x-latest.args
create mode 100644
tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.s390x-latest.xml
create mode 100644 tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.xml
diff --git a/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.s390x-latest.args
b/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.s390x-latest.args
new file mode 100644
index 0000000000..9704d7d5e9
--- /dev/null
+++ b/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.s390x-latest.args
@@ -0,0 +1,41 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1 \
+USER=test \
+LOGNAME=test \
+XDG_DATA_HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1/.local/share \
+XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1/.cache \
+XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1/.config \
+/usr/bin/qemu-system-s390x \
+-name guest=QEMUGuest1,debug-threads=on \
+-S \
+-object
'{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain--1-QEMUGuest1/master-key.aes"}'
\
+-machine s390-ccw-virtio,usb=off,dump-guest-core=off \
+-accel kvm \
+-cpu gen16a-base \
+-m size=2095104k,maxmem=1099511627776k \
+-overcommit mem-lock=off \
+-smp 2,sockets=2,cores=1,threads=1 \
+-object
'{"qom-type":"memory-backend-ram","id":"ram-node0","size":2145386496}'
\
+-numa node,nodeid=0,cpus=0-1,memdev=ram-node0 \
+-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
+-display none \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,fd=1729,server=on,wait=off \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot strict=on \
+-device
'{"driver":"zpci","uid":1,"fid":0,"target":"pci.1","id":"zpci1"}'
\
+-device
'{"driver":"pci-bridge","chassis_nr":1,"id":"pci.1","bus":"pci.0","addr":"0x1"}'
\
+-object
'{"qom-type":"memory-backend-ram","id":"memvirtiomem0","reserve":false,"size":1073741824}'
\
+-device
'{"driver":"virtio-mem-pci","node":0,"block-size":2097152,"requested-size":536870912,"memdev":"memvirtiomem0","id":"virtiomem0","bus":"pci.0","addr":"0x2"}'
\
+-object
'{"qom-type":"memory-backend-file","id":"memvirtiomem1","mem-path":"/dev/hugepages2M/libvirt/qemu/-1-QEMUGuest1","reserve":false,"size":2147483648,"host-nodes":[1,2,3],"policy":"bind"}'
\
+-device
'{"driver":"virtio-mem-pci","node":0,"block-size":2097152,"requested-size":1073741824,"memdev":"memvirtiomem1","prealloc":true,"memaddr":5637144576,"dynamic-memslots":true,"id":"virtiomem1","bus":"pci.1","addr":"0x1"}'
\
+-blockdev
'{"driver":"host_device","filename":"/dev/HostVG/QEMUGuest1","node-name":"libvirt-1-storage","read-only":false}'
\
+-device
'{"driver":"virtio-blk-ccw","devno":"fe.0.0000","drive":"libvirt-1-storage","id":"virtio-disk0","bootindex":1}'
\
+-audiodev
'{"id":"audio1","driver":"none"}' \
+-device
'{"driver":"virtio-balloon-ccw","id":"balloon0","devno":"fe.0.0001"}'
\
+-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
+-msg timestamp=on
diff --git a/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.s390x-latest.xml
b/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.s390x-latest.xml
new file mode 100644
index 0000000000..336c6e5aac
--- /dev/null
+++ b/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.s390x-latest.xml
@@ -0,0 +1,71 @@
+<domain type='kvm'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <maxMemory unit='KiB'>1099511627776</maxMemory>
+ <memory unit='KiB'>8388608</memory>
+ <currentMemory unit='KiB'>8388608</currentMemory>
+ <vcpu placement='static' cpuset='0-1'>2</vcpu>
+ <os>
+ <type arch='s390x' machine='s390-ccw-virtio'>hvm</type>
+ <boot dev='hd'/>
+ </os>
+ <cpu mode='custom' match='exact' check='none'>
+ <model fallback='forbid'>gen16a-base</model>
+ <numa>
+ <cell id='0' cpus='0-1' memory='2095104'
unit='KiB'/>
+ </numa>
+ </cpu>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>destroy</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu-system-s390x</emulator>
+ <disk type='block' device='disk'>
+ <driver name='qemu' type='raw'/>
+ <source dev='/dev/HostVG/QEMUGuest1'/>
+ <target dev='hda' bus='virtio'/>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x0000'/>
+ </disk>
+ <controller type='pci' index='0' model='pci-root'/>
+ <controller type='pci' index='1' model='pci-bridge'>
+ <model name='pci-bridge'/>
+ <target chassisNr='1'/>
+ <address type='pci' domain='0x0000' bus='0x00'
slot='0x01' function='0x0'>
+ <zpci uid='0x0001' fid='0x00000000'/>
+ </address>
+ </controller>
+ <audio id='1' type='none'/>
+ <memballoon model='virtio'>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x0001'/>
+ </memballoon>
+ <panic model='s390'/>
+ <memory model='virtio-mem'>
+ <target>
+ <size unit='KiB'>1048576</size>
+ <node>0</node>
+ <block unit='KiB'>2048</block>
+ <requested unit='KiB'>524288</requested>
+ </target>
+ <address type='pci' domain='0x0000' bus='0x00'
slot='0x02' function='0x0'>
+ <zpci uid='0x0002' fid='0x00000001'/>
+ </address>
+ </memory>
+ <memory model='virtio-mem'>
+ <source>
+ <nodemask>1-3</nodemask>
+ <pagesize unit='KiB'>2048</pagesize>
+ </source>
+ <target dynamicMemslots='yes'>
+ <size unit='KiB'>2097152</size>
+ <node>0</node>
+ <block unit='KiB'>2048</block>
+ <requested unit='KiB'>1048576</requested>
+ <address base='0x150000000'/>
+ </target>
+ <address type='pci' domain='0x0000' bus='0x01'
slot='0x01' function='0x0'>
+ <zpci uid='0x0003' fid='0x00000002'/>
+ </address>
+ </memory>
+ </devices>
+</domain>
diff --git a/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.xml
b/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.xml
new file mode 100644
index 0000000000..747877042a
--- /dev/null
+++ b/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.xml
@@ -0,0 +1,59 @@
+<domain type='kvm'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <maxMemory unit='KiB'>1099511627776</maxMemory>
+ <memory unit='KiB'>8388608</memory>
+ <currentMemory unit='KiB'>8388608</currentMemory>
+ <vcpu placement='static' cpuset='0-1'>2</vcpu>
+ <os>
+ <type arch='s390x' machine='s390-ccw-virtio'>hvm</type>
+ <boot dev='hd'/>
+ </os>
+ <cpu mode='custom' match='exact' check='none'>
+ <model fallback='forbid'>gen16a-base</model>
+ <numa>
+ <cell id='0' cpus='0-1' memory='2095104'
unit='KiB'/>
+ </numa>
+ </cpu>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>destroy</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu-system-s390x</emulator>
+ <disk type='block' device='disk'>
+ <driver name='qemu' type='raw'/>
+ <source dev='/dev/HostVG/QEMUGuest1'/>
+ <target dev='hda' bus='virtio'/>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x0000'/>
+ </disk>
+ <controller type='pci' index='0' model='pci-root'/>
+ <audio id='1' type='none'/>
+ <memballoon model='virtio'>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x0001'/>
+ </memballoon>
+ <memory model='virtio-mem'>
+ <target>
+ <size unit='KiB'>1048576</size>
+ <node>0</node>
+ <block unit='KiB'>2048</block>
+ <requested unit='KiB'>524288</requested>
+ </target>
+ <address type='pci' domain='0x0000' bus='0x00'
slot='0x02' function='0x0'/>
+ </memory>
+ <memory model='virtio-mem'>
+ <source>
+ <nodemask>1-3</nodemask>
+ <pagesize unit='KiB'>2048</pagesize>
+ </source>
+ <target dynamicMemslots='yes'>
+ <size unit='KiB'>2097152</size>
+ <node>0</node>
+ <block unit='KiB'>2048</block>
+ <requested unit='KiB'>1048576</requested>
+ <address base='0x150000000'/>
+ </target>
+ <address type='pci' domain='0x0000' bus='0x01'
slot='0x01' function='0x0'/>
+ </memory>
+ </devices>
+</domain>
diff --git a/tests/qemuxmlconftest.c b/tests/qemuxmlconftest.c
index 49f13d1c6b..768c0ce34e 100644
--- a/tests/qemuxmlconftest.c
+++ b/tests/qemuxmlconftest.c
@@ -2715,6 +2715,7 @@ mymain(void)
* virDomainMemoryDefCheckConflict() works for NVDIMMs which are special
* than other memory devices because of how they handle <labelsize/> */
DO_TEST_CAPS_LATEST("memory-hotplug-nvdimm-overlap");
+ DO_TEST_CAPS_ARCH_LATEST("memory-hotplug-virtio-mem-pci-s390x",
"s390x");
DO_TEST_CAPS_ARCH_LATEST("machine-aeskeywrap-on-caps", "s390x");
DO_TEST_CAPS_ARCH_LATEST("machine-aeskeywrap-on-cap", "s390x");
--
2.45.3
5:48 p.m.
New subject: [PATCH v2 3/8] qemuxmlconftest: Introduce
memory-hotplug-virtio-mem-pci-s390x.xml
Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com>
On 2/3/25 10:55, Michal Privoznik wrote:
As of v9.2.0-1413-gd77ae821e8 QEMU supports virtio-mem-pci on
s390 too. Let's add a test case for that.
Signed-off-by: Michal Privoznik<mprivozn(a)redhat.com>
---
...lug-virtio-mem-pci-s390x.s390x-latest.args | 41 +++++++++++
...plug-virtio-mem-pci-s390x.s390x-latest.xml | 71 +++++++++++++++++++
.../memory-hotplug-virtio-mem-pci-s390x.xml | 59 +++++++++++++++
tests/qemuxmlconftest.c | 1 +
4 files changed, 172 insertions(+)
create mode 100644
tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.s390x-latest.args
create mode 100644
tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.s390x-latest.xml
create mode 100644 tests/qemuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.xml
--
Mit freundlichen Grüßen/Kind regards
Boris Fiuczynski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Wolfgang Wendt
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
12:55 p.m.
New subject: [PATCH v2 4/8] qemu_caps: Introduce QEMU_CAPS_DEVICE_VIRTIO_MEM_CCW
This capability tracks whether QEMU supports virtio-mem-ccw
device. Introduced in QEMU commit v9.2.0-492-gaa910c20ec only
upcoming release of QEMU supports the device.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com>
---
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h | 1 +
tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml | 1 +
3 files changed, 4 insertions(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 490f5b28fd..3dadb2e53e 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -726,6 +726,7 @@ VIR_ENUM_IMPL(virQEMUCaps,
/* 470 */
"migrate-incoming.exit-on-error", /*
QEMU_CAPS_MIGRATE_INCOMING_EXIT_ON_ERROR */
"machine.virt.aia", /* QEMU_CAPS_MACHINE_VIRT_AIA */
+ "virtio-mem-ccw", /* QEMU_CAPS_DEVICE_VIRTIO_MEM_CCW */
);
@@ -1414,6 +1415,7 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = {
{ "virtio-sound-device", QEMU_CAPS_DEVICE_VIRTIO_SOUND },
{ "sev-snp-guest", QEMU_CAPS_SEV_SNP_GUEST },
{ "acpi-erst", QEMU_CAPS_DEVICE_ACPI_ERST },
+ { "virtio-mem-ccw", QEMU_CAPS_DEVICE_VIRTIO_MEM_CCW },
};
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index 07746f644c..9eb55b6420 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -705,6 +705,7 @@ typedef enum { /* virQEMUCapsFlags grouping marker for syntax-check
*/
/* 470 */
QEMU_CAPS_MIGRATE_INCOMING_EXIT_ON_ERROR, /* exit-on-error argument of
migrate-incoming command */
QEMU_CAPS_MACHINE_VIRT_AIA, /* -machine virt,aia=(none|aplic|aplic-imsic), RISC-V
only */
+ QEMU_CAPS_DEVICE_VIRTIO_MEM_CCW, /* -device virtio-mem-ccw */
QEMU_CAPS_LAST /* this must always be the last item */
} virQEMUCapsFlags;
diff --git a/tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml
b/tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml
index 242848d6ae..bccce19bfc 100644
--- a/tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml
+++ b/tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml
@@ -141,6 +141,7 @@
<flag name='netdev-stream-reconnect-miliseconds'/>
<flag name='query-cpu-model-expansion.deprecated-props'/>
<flag name='migrate-incoming.exit-on-error'/>
+ <flag name='virtio-mem-ccw'/>
<version>9002050</version>
<microcodeVersion>39100285</microcodeVersion>
<package>v9.2.0-1203-gd6430c17d7</package>
--
2.45.3
12:55 p.m.
New subject: [PATCH v2 5/8] qemu: Validate virtio-mem-ccw
There are basically two differences between virtio-mem-ccw and
virtio-mem-pci. s390 doesn't allow mixing different page sizes
and there's no NUMA support in QEMU.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com>
---
src/qemu/qemu_validate.c | 35 ++++++++++++++++++++++++++++++++---
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c
index c8ea8b63d2..76f2eafe49 100644
--- a/src/qemu/qemu_validate.c
+++ b/src/qemu/qemu_validate.c
@@ -5224,7 +5224,8 @@ qemuValidateDomainDeviceDefHub(virDomainHubDef *hub,
static int
-qemuValidateDomainDeviceDefMemory(virDomainMemoryDef *mem,
+qemuValidateDomainDeviceDefMemory(const virDomainMemoryDef *mem,
+ const virDomainDef *def,
virQEMUCaps *qemuCaps)
{
virSGXCapability *sgxCaps;
@@ -5263,12 +5264,40 @@ qemuValidateDomainDeviceDefMemory(virDomainMemoryDef *mem,
break;
case VIR_DOMAIN_MEMORY_MODEL_VIRTIO_MEM:
- if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI)) {
+ if ((mem->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI &&
+ !virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI)) ||
+ (mem->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW &&
+ !virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_MEM_CCW))) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("virtio-mem isn't supported by this QEMU
binary"));
return -1;
}
+ if (mem->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW) {
+ /* virtio-mem-ccw has a few differences compared to virtio-mem-pci:
+ *
+ * 1) corresponding memory-backing-* object can't have a different
+ * page size than the boot memory (see s390_machine_device_plug()
+ * in qemu sources).
+ * 2) Since its commit v2.12.0-rc0~41^2~6 QEMU doesn't allow NUMA
+ * for s390.
+ */
+
+ if (mem->source.virtio_mem.pagesize != 0 &&
+ def->mem.nhugepages &&
+ mem->source.virtio_mem.pagesize != def->mem.hugepages[0].size) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("virtio-mem-ccw can't use different page size
than the boot memory"));
+ return -1;
+ }
+
+ if (mem->targetNode != 0 && mem->targetNode != -1) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("NUMA nodes are not supported for
virtio-mem-ccw"));
+ return -1;
+ }
+ }
+
if (mem->target.virtio_mem.dynamicMemslots == VIR_TRISTATE_BOOL_YES
&&
!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI_DYNAMIC_MEMSLOTS))
{
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
@@ -5455,7 +5484,7 @@ qemuValidateDomainDeviceDef(const virDomainDeviceDef *dev,
return qemuValidateDomainDeviceDefSound(dev->data.sound, qemuCaps);
case VIR_DOMAIN_DEVICE_MEMORY:
- return qemuValidateDomainDeviceDefMemory(dev->data.memory, qemuCaps);
+ return qemuValidateDomainDeviceDefMemory(dev->data.memory, def, qemuCaps);
case VIR_DOMAIN_DEVICE_SHMEM:
return qemuValidateDomainDeviceDefShmem(dev->data.shmem, qemuCaps);
--
2.45.3
12:13 p.m.
New subject: [PATCH v2 5/8] qemu: Validate virtio-mem-ccw
On 03.02.25 10:55, Michal Privoznik wrote:
There are basically two differences between virtio-mem-ccw and
virtio-mem-pci. s390 doesn't allow mixing different page sizes
and there's no NUMA support in QEMU.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com>
---
src/qemu/qemu_validate.c | 35 ++++++++++++++++++++++++++++++++---
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c
index c8ea8b63d2..76f2eafe49 100644
--- a/src/qemu/qemu_validate.c
+++ b/src/qemu/qemu_validate.c
@@ -5224,7 +5224,8 @@ qemuValidateDomainDeviceDefHub(virDomainHubDef *hub,
static int
-qemuValidateDomainDeviceDefMemory(virDomainMemoryDef *mem,
+qemuValidateDomainDeviceDefMemory(const virDomainMemoryDef *mem,
+ const virDomainDef *def,
virQEMUCaps *qemuCaps)
{
virSGXCapability *sgxCaps;
@@ -5263,12 +5264,40 @@ qemuValidateDomainDeviceDefMemory(virDomainMemoryDef *mem,
break;
case VIR_DOMAIN_MEMORY_MODEL_VIRTIO_MEM:
- if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI)) {
+ if ((mem->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI &&
+ !virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI)) ||
+ (mem->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW &&
+ !virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_MEM_CCW))) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("virtio-mem isn't supported by this QEMU
binary"));
return -1;
}
+ if (mem->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW) {
+ /* virtio-mem-ccw has a few differences compared to virtio-mem-pci:
+ *
+ * 1) corresponding memory-backing-* object can't have a different
+ * page size than the boot memory (see s390_machine_device_plug()
+ * in qemu sources).
Hm, but that also applies to virtio-mem-pci on s390x.
To be precise: this is a KVM limitation, but we currently check for it
even under TCG. I should probably change that, to not apply for TCG, but
I'll have to look into the details if my memory is correct.
So 1), in theory, applies with KVM, and independent of PCI vs. CCW.
+ * 2) Since its commit v2.12.0-rc0~41^2~6 QEMU
doesn't allow NUMA
+ * for s390.
Similar: this is also independent of PCI vs. CCW?
Thanks!
--
Cheers,
David / dhildenb
12:25 p.m.
New subject: [PATCH v2 5/8] qemu: Validate virtio-mem-ccw
On 04.02.25 10:13, David Hildenbrand wrote:
On 03.02.25 10:55, Michal Privoznik wrote:
> There are basically two differences between virtio-mem-ccw and
> virtio-mem-pci. s390 doesn't allow mixing different page sizes
> and there's no NUMA support in QEMU.
>
> Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
> Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com>
> ---
> src/qemu/qemu_validate.c | 35 ++++++++++++++++++++++++++++++++---
> 1 file changed, 32 insertions(+), 3 deletions(-)
>
> diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c
> index c8ea8b63d2..76f2eafe49 100644
> --- a/src/qemu/qemu_validate.c
> +++ b/src/qemu/qemu_validate.c
> @@ -5224,7 +5224,8 @@ qemuValidateDomainDeviceDefHub(virDomainHubDef *hub,
>
>
> static int
> -qemuValidateDomainDeviceDefMemory(virDomainMemoryDef *mem,
> +qemuValidateDomainDeviceDefMemory(const virDomainMemoryDef *mem,
> + const virDomainDef *def,
> virQEMUCaps *qemuCaps)
> {
> virSGXCapability *sgxCaps;
> @@ -5263,12 +5264,40 @@ qemuValidateDomainDeviceDefMemory(virDomainMemoryDef *mem,
> break;
>
> case VIR_DOMAIN_MEMORY_MODEL_VIRTIO_MEM:
> - if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI)) {
> + if ((mem->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI &&
> + !virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI)) ||
> + (mem->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW &&
> + !virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIRTIO_MEM_CCW))) {
> virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> _("virtio-mem isn't supported by this QEMU
binary"));
> return -1;
> }
>
> + if (mem->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW) {
> + /* virtio-mem-ccw has a few differences compared to virtio-mem-pci:
> + *
> + * 1) corresponding memory-backing-* object can't have a different
> + * page size than the boot memory (see s390_machine_device_plug()
> + * in qemu sources).
Hm, but that also applies to virtio-mem-pci on s390x.
To be precise: this is a KVM limitation, but we currently check for it
even under TCG. I should probably change that, to not apply for TCG, but
I'll have to look into the details if my memory is correct.
Ah, and now I reread my own comment:
"While only relevant for KVM, there is not really any use case for this
with TCG, so we'll unconditionally reject it."
So we can just assume that we cannot mix page sizes with a s390x
machine, independent of KVM vs. TCG.
--
Cheers,
David / dhildenb
12:55 p.m.
New subject: [PATCH v2 6/8] qemu: Allow virtio-mem on CCW
After previous commits, we can allow virtio-mem to live on CCW
channel.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com>
---
src/qemu/qemu_domain.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 6554b992f0..56f86140cd 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -7673,9 +7673,10 @@ qemuDomainDefValidateMemoryHotplugDevice(const virDomainMemoryDef
*mem,
case VIR_DOMAIN_MEMORY_MODEL_VIRTIO_MEM:
if (mem->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI &&
+ mem->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_CCW &&
mem->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
- _("only 'pci' addresses are supported for the
%1$s device"),
+ _("only 'pci' and 'ccw' addresses are
supported for the %1$s device"),
virDomainMemoryModelTypeToString(mem->model));
return -1;
}
--
2.45.3
12:55 p.m.
New subject: [PATCH v2 7/8] qemuxmlconftest: Introduce memory-hotplug-virtio-mem-ccw-s390x.xml
This is similar to emuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.xml
except the explicit placement of virtio-mem onto a PCI bus is removed.
This results in virtio-mem being placed onto CCW "bus" this demonstrating
previous commits working as expected.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
...lug-virtio-mem-ccw-s390x.s390x-latest.args | 39 ++++++++++++
...plug-virtio-mem-ccw-s390x.s390x-latest.xml | 60 +++++++++++++++++++
.../memory-hotplug-virtio-mem-ccw-s390x.xml | 57 ++++++++++++++++++
tests/qemuxmlconftest.c | 1 +
4 files changed, 157 insertions(+)
create mode 100644
tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.s390x-latest.args
create mode 100644
tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.s390x-latest.xml
create mode 100644 tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.xml
diff --git a/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.s390x-latest.args
b/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.s390x-latest.args
new file mode 100644
index 0000000000..a6bbef5ce7
--- /dev/null
+++ b/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.s390x-latest.args
@@ -0,0 +1,39 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1 \
+USER=test \
+LOGNAME=test \
+XDG_DATA_HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1/.local/share \
+XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1/.cache \
+XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1/.config \
+/usr/bin/qemu-system-s390x \
+-name guest=QEMUGuest1,debug-threads=on \
+-S \
+-object
'{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain--1-QEMUGuest1/master-key.aes"}'
\
+-machine s390-ccw-virtio,usb=off,dump-guest-core=off \
+-accel kvm \
+-cpu gen16a-base \
+-m size=2095104k,maxmem=1099511627776k \
+-overcommit mem-lock=off \
+-smp 2,sockets=2,cores=1,threads=1 \
+-object
'{"qom-type":"memory-backend-ram","id":"ram-node0","size":2145386496}'
\
+-numa node,nodeid=0,cpus=0-1,memdev=ram-node0 \
+-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
+-display none \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,fd=1729,server=on,wait=off \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot strict=on \
+-object
'{"qom-type":"memory-backend-ram","id":"memvirtiomem0","reserve":false,"size":1073741824}'
\
+-device
'{"driver":"virtio-mem-ccw","node":0,"block-size":2097152,"requested-size":536870912,"memdev":"memvirtiomem0","id":"virtiomem0","devno":"fe.0.0002"}'
\
+-object
'{"qom-type":"memory-backend-file","id":"memvirtiomem1","mem-path":"/dev/hugepages2M/libvirt/qemu/-1-QEMUGuest1","reserve":false,"size":2147483648,"host-nodes":[1,2,3],"policy":"bind"}'
\
+-device
'{"driver":"virtio-mem-ccw","node":0,"block-size":2097152,"requested-size":1073741824,"memdev":"memvirtiomem1","prealloc":true,"memaddr":5637144576,"dynamic-memslots":true,"id":"virtiomem1","devno":"fe.0.0003"}'
\
+-blockdev
'{"driver":"host_device","filename":"/dev/HostVG/QEMUGuest1","node-name":"libvirt-1-storage","read-only":false}'
\
+-device
'{"driver":"virtio-blk-ccw","devno":"fe.0.0000","drive":"libvirt-1-storage","id":"virtio-disk0","bootindex":1}'
\
+-audiodev
'{"id":"audio1","driver":"none"}' \
+-device
'{"driver":"virtio-balloon-ccw","id":"balloon0","devno":"fe.0.0001"}'
\
+-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
+-msg timestamp=on
diff --git a/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.s390x-latest.xml
b/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.s390x-latest.xml
new file mode 100644
index 0000000000..fe18b1ec7b
--- /dev/null
+++ b/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.s390x-latest.xml
@@ -0,0 +1,60 @@
+<domain type='kvm'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <maxMemory unit='KiB'>1099511627776</maxMemory>
+ <memory unit='KiB'>8388608</memory>
+ <currentMemory unit='KiB'>8388608</currentMemory>
+ <vcpu placement='static' cpuset='0-1'>2</vcpu>
+ <os>
+ <type arch='s390x' machine='s390-ccw-virtio'>hvm</type>
+ <boot dev='hd'/>
+ </os>
+ <cpu mode='custom' match='exact' check='none'>
+ <model fallback='forbid'>gen16a-base</model>
+ <numa>
+ <cell id='0' cpus='0-1' memory='2095104'
unit='KiB'/>
+ </numa>
+ </cpu>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>destroy</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu-system-s390x</emulator>
+ <disk type='block' device='disk'>
+ <driver name='qemu' type='raw'/>
+ <source dev='/dev/HostVG/QEMUGuest1'/>
+ <target dev='hda' bus='virtio'/>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x0000'/>
+ </disk>
+ <controller type='pci' index='0' model='pci-root'/>
+ <audio id='1' type='none'/>
+ <memballoon model='virtio'>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x0001'/>
+ </memballoon>
+ <panic model='s390'/>
+ <memory model='virtio-mem'>
+ <target>
+ <size unit='KiB'>1048576</size>
+ <node>0</node>
+ <block unit='KiB'>2048</block>
+ <requested unit='KiB'>524288</requested>
+ </target>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x0002'/>
+ </memory>
+ <memory model='virtio-mem'>
+ <source>
+ <nodemask>1-3</nodemask>
+ <pagesize unit='KiB'>2048</pagesize>
+ </source>
+ <target dynamicMemslots='yes'>
+ <size unit='KiB'>2097152</size>
+ <node>0</node>
+ <block unit='KiB'>2048</block>
+ <requested unit='KiB'>1048576</requested>
+ <address base='0x150000000'/>
+ </target>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x0003'/>
+ </memory>
+ </devices>
+</domain>
diff --git a/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.xml
b/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.xml
new file mode 100644
index 0000000000..4f9f90d1e2
--- /dev/null
+++ b/tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.xml
@@ -0,0 +1,57 @@
+<domain type='kvm'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <maxMemory unit='KiB'>1099511627776</maxMemory>
+ <memory unit='KiB'>8388608</memory>
+ <currentMemory unit='KiB'>8388608</currentMemory>
+ <vcpu placement='static' cpuset='0-1'>2</vcpu>
+ <os>
+ <type arch='s390x' machine='s390-ccw-virtio'>hvm</type>
+ <boot dev='hd'/>
+ </os>
+ <cpu mode='custom' match='exact' check='none'>
+ <model fallback='forbid'>gen16a-base</model>
+ <numa>
+ <cell id='0' cpus='0-1' memory='2095104'
unit='KiB'/>
+ </numa>
+ </cpu>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>destroy</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu-system-s390x</emulator>
+ <disk type='block' device='disk'>
+ <driver name='qemu' type='raw'/>
+ <source dev='/dev/HostVG/QEMUGuest1'/>
+ <target dev='hda' bus='virtio'/>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x0000'/>
+ </disk>
+ <controller type='pci' index='0' model='pci-root'/>
+ <audio id='1' type='none'/>
+ <memballoon model='virtio'>
+ <address type='ccw' cssid='0xfe' ssid='0x0'
devno='0x0001'/>
+ </memballoon>
+ <memory model='virtio-mem'>
+ <target>
+ <size unit='KiB'>1048576</size>
+ <node>0</node>
+ <block unit='KiB'>2048</block>
+ <requested unit='KiB'>524288</requested>
+ </target>
+ </memory>
+ <memory model='virtio-mem'>
+ <source>
+ <nodemask>1-3</nodemask>
+ <pagesize unit='KiB'>2048</pagesize>
+ </source>
+ <target dynamicMemslots='yes'>
+ <size unit='KiB'>2097152</size>
+ <node>0</node>
+ <block unit='KiB'>2048</block>
+ <requested unit='KiB'>1048576</requested>
+ <address base='0x150000000'/>
+ </target>
+ </memory>
+ </devices>
+</domain>
diff --git a/tests/qemuxmlconftest.c b/tests/qemuxmlconftest.c
index 768c0ce34e..3ddb19a7ed 100644
--- a/tests/qemuxmlconftest.c
+++ b/tests/qemuxmlconftest.c
@@ -2716,6 +2716,7 @@ mymain(void)
* than other memory devices because of how they handle <labelsize/> */
DO_TEST_CAPS_LATEST("memory-hotplug-nvdimm-overlap");
DO_TEST_CAPS_ARCH_LATEST("memory-hotplug-virtio-mem-pci-s390x",
"s390x");
+ DO_TEST_CAPS_ARCH_LATEST("memory-hotplug-virtio-mem-ccw-s390x",
"s390x");
DO_TEST_CAPS_ARCH_LATEST("machine-aeskeywrap-on-caps", "s390x");
DO_TEST_CAPS_ARCH_LATEST("machine-aeskeywrap-on-cap", "s390x");
--
2.45.3
5:49 p.m.
New subject: [PATCH v2 7/8] qemuxmlconftest: Introduce
memory-hotplug-virtio-mem-ccw-s390x.xml
Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com>
On 2/3/25 10:55, Michal Privoznik wrote:
This is similar to
emuxmlconfdata/memory-hotplug-virtio-mem-pci-s390x.xml
except the explicit placement of virtio-mem onto a PCI bus is removed.
This results in virtio-mem being placed onto CCW "bus" this demonstrating
previous commits working as expected.
Signed-off-by: Michal Privoznik<mprivozn(a)redhat.com>
---
...lug-virtio-mem-ccw-s390x.s390x-latest.args | 39 ++++++++++++
...plug-virtio-mem-ccw-s390x.s390x-latest.xml | 60 +++++++++++++++++++
.../memory-hotplug-virtio-mem-ccw-s390x.xml | 57 ++++++++++++++++++
tests/qemuxmlconftest.c | 1 +
4 files changed, 157 insertions(+)
create mode 100644
tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.s390x-latest.args
create mode 100644
tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.s390x-latest.xml
create mode 100644 tests/qemuxmlconfdata/memory-hotplug-virtio-mem-ccw-s390x.xml
--
Mit freundlichen Grüßen/Kind regards
Boris Fiuczynski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Wolfgang Wendt
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
12:55 p.m.
New subject: [PATCH v2 8/8] NEWS: Document virtio-mem-ccw
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com>
---
NEWS.rst | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 20bf01c8d7..4b60cf0060 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -38,6 +38,11 @@ v11.1.0 (unreleased)
etc. Libvirt will now read these events and take actions such as
updating domain state, etc.
+ * Introduce virtio-mem ``<memory/>`` model for s390 guests
+
+ The virtio-mem model of ``<memory/>`` device can now be used with s390
+ guests.
+
* **Improvements**
* **Bug fixes**
--
2.45.3
12:06 p.m.
On 03.02.25 10:55, Michal Privoznik wrote:
I should probably play with this myself, but due to lack of a test
system where I can mess with systemd:
Assuming we're on a s390x host (using KVM) and we specify:
+ <memory model='virtio-mem'>
+ <target dynamicMemslots='yes'>
+ <size unit='KiB'>2097152</size>
+ <node>0</node>
+ <requested unit='KiB'>1048576</requested>
+ </target>
+ </memory>
In particular, without
+ <block unit='KiB'>2048</block>
What would be the default value on a s390x host?
In QEMU, we'd be using the default of 1 MiB on a s390x host, which
corresponds to the THP size. Note that on an x86_64 host, the default
will be 2 MiB.
Ideally, we'd also be using the default of 1 MiB on an s390x host.
How is the default value determined here?
Thanks!
--
Cheers,
David / dhildenb
12:57 p.m.
On 2/4/25 10:06, David Hildenbrand wrote:
On 03.02.25 10:55, Michal Privoznik wrote:
> v2 of:
>
> https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/
> thread/KA2DGRIY7DAMNMYM4MBKLOJCB7YYEUKU/
>
I should probably play with this myself, but due to lack of a test
system where I can mess with systemd:
Assuming we're on a s390x host (using KVM) and we specify:
+ <memory model='virtio-mem'>
+ <target dynamicMemslots='yes'>
+ <size unit='KiB'>2097152</size>
+ <node>0</node>
+ <requested unit='KiB'>1048576</requested>
+ </target>
+ </memory>
In particular, without
+ <block unit='KiB'>2048</block>
What would be the default value on a s390x host?
In QEMU, we'd be using the default of 1 MiB on a s390x host, which
corresponds to the THP size. Note that on an x86_64 host, the default
will be 2 MiB.
Ideally, we'd also be using the default of 1 MiB on an s390x host.
How is the default value determined here?
Thanks!
Current libvirt implementation does not generate a default.
When not providing the element block an error occurs:
error: block size must be a power of two
When providing the element block the required minimum value is 1024KiB.
--
Mit freundlichen Grüßen/Kind regards
Boris Fiuczynski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Wolfgang Wendt
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
1:04 p.m.
On 04.02.25 10:57, Boris Fiuczynski wrote:
On 2/4/25 10:06, David Hildenbrand wrote:
> On 03.02.25 10:55, Michal Privoznik wrote:
>> v2 of:
>>
>> https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/
>> thread/KA2DGRIY7DAMNMYM4MBKLOJCB7YYEUKU/
>>
>
> I should probably play with this myself, but due to lack of a test
> system where I can mess with systemd:
>
> Assuming we're on a s390x host (using KVM) and we specify:
>
> + <memory model='virtio-mem'>
> + <target dynamicMemslots='yes'>
> + <size unit='KiB'>2097152</size>
> + <node>0</node>
> + <requested unit='KiB'>1048576</requested>
> + </target>
> + </memory>
>
> In particular, without
>
> + <block unit='KiB'>2048</block>
>
> What would be the default value on a s390x host?
>
> In QEMU, we'd be using the default of 1 MiB on a s390x host, which
> corresponds to the THP size. Note that on an x86_64 host, the default
> will be 2 MiB.
>
> Ideally, we'd also be using the default of 1 MiB on an s390x host.
>
> How is the default value determined here?
>
> Thanks!
>
Current libvirt implementation does not generate a default.
When not providing the element block an error occurs:
error: block size must be a power of two
When providing the element block the required minimum value is 1024KiB.
Right, the 1 MiB minimum value independent of the memory backed is
currently enforced by QEMU.
Interesting that no defaults are provided. I assume it might be an
interesting idea to query the default from QEMU, instead of
re-implementing that logic in libvirt.
--
Cheers,
David / dhildenb
1:16 p.m.
On 2/4/25 11:04, David Hildenbrand wrote:
On 04.02.25 10:57, Boris Fiuczynski wrote:
> On 2/4/25 10:06, David Hildenbrand wrote:
>> On 03.02.25 10:55, Michal Privoznik wrote:
>>> v2 of:
>>>
>>> https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/
>>> thread/KA2DGRIY7DAMNMYM4MBKLOJCB7YYEUKU/
>>>
>>
>> I should probably play with this myself, but due to lack of a test
>> system where I can mess with systemd:
>>
>> Assuming we're on a s390x host (using KVM) and we specify:
>>
>> + <memory model='virtio-mem'>
>> + <target dynamicMemslots='yes'>
>> + <size unit='KiB'>2097152</size>
>> + <node>0</node>
>> + <requested unit='KiB'>1048576</requested>
>> + </target>
>> + </memory>
>>
>> In particular, without
>>
>> + <block unit='KiB'>2048</block>
>>
>> What would be the default value on a s390x host?
>>
>> In QEMU, we'd be using the default of 1 MiB on a s390x host, which
>> corresponds to the THP size. Note that on an x86_64 host, the default
>> will be 2 MiB.
>>
>> Ideally, we'd also be using the default of 1 MiB on an s390x host.
>>
>> How is the default value determined here?
>>
>> Thanks!
>>
>
> Current libvirt implementation does not generate a default.
> When not providing the element block an error occurs:
> error: block size must be a power of two
> When providing the element block the required minimum value is 1024KiB.
Right, the 1 MiB minimum value independent of the memory backed is
currently enforced by QEMU.
The validation is done by libvirt in the domain validation in which QEMU
is not involved.
Interesting that no defaults are provided. I assume it might be an
interesting idea to query the default from QEMU, instead of re-
implementing that logic in libvirt.
Usually the later is done when a default is set by libvirt and is not
required to be provided by the user.
--
Mit freundlichen Grüßen/Kind regards
Boris Fiuczynski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Wolfgang Wendt
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
1
days inactive
2
days old
16 comments
3 participants
participants (3)
-
Boris Fiuczynski -
David Hildenbrand -
Michal Privoznik