[PATCH v3 0/2] qemu: Do not use canonical path for system memory

v3 of: https://listman.redhat.com/archives/libvir-list/2021-January/msg00684.html diff to v2: - Rebased as new capabilities and capabilities files were added since v2 - Replaced imaginary QEMU commit $HASH with actual commit hash (QEMU part was merged meanwhile) - Worked in Peter's review of v2 Michal Prívozník (2): qemu_capabilities: Introduce QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID qemu: Do not Use canonical path for system memory src/qemu/qemu_capabilities.c | 6 ++++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 35 ++++++++++++++++--- src/qemu/qemu_command.h | 3 +- src/qemu/qemu_hotplug.c | 2 +- .../caps_4.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1 + .../caps_4.0.0.riscv32.xml | 1 + .../caps_4.0.0.riscv64.xml | 1 + .../qemucapabilitiesdata/caps_4.0.0.s390x.xml | 1 + .../caps_4.0.0.x86_64.xml | 1 + .../caps_4.1.0.x86_64.xml | 1 + .../caps_4.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 + .../qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 + .../caps_4.2.0.x86_64.xml | 1 + .../caps_5.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 + .../caps_5.0.0.riscv64.xml | 1 + .../caps_5.0.0.x86_64.xml | 1 + .../qemucapabilitiesdata/caps_5.1.0.sparc.xml | 1 + .../caps_5.1.0.x86_64.xml | 1 + .../caps_5.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 1 + .../caps_5.2.0.riscv64.xml | 1 + .../qemucapabilitiesdata/caps_5.2.0.s390x.xml | 1 + .../caps_5.2.0.x86_64.xml | 1 + .../caps_6.0.0.x86_64.xml | 1 + .../disk-vhostuser.x86_64-latest.args | 3 +- .../hugepages-memaccess3.x86_64-latest.args | 4 +-- 30 files changed, 68 insertions(+), 9 deletions(-) -- 2.26.2

This capability tracks whether memory-backend-file has "x-use-canonical-path-for-ramblock-id" attribute. Introduced into QEMU by commit fa0cb34d2210cc749b9a70db99bb41c56ad20831. As of QEMU commit 8db0b20415c129cf5e577a593a4a0372d90b7cc9 the property is considered stable by qemu despite the 'x-' prefix to preserve compatibility with released qemu versions. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- src/qemu/qemu_capabilities.c | 6 ++++++ src/qemu/qemu_capabilities.h | 1 + tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml | 1 + tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml | 1 + tests/qemucapabilitiesdata/caps_4.0.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_4.0.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_4.1.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_4.2.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_4.2.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_5.0.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_5.0.0.riscv64.xml | 1 + tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_5.1.0.sparc.xml | 1 + tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_5.2.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_5.2.0.riscv64.xml | 1 + tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml | 1 + 25 files changed, 30 insertions(+) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index ebd6607888..cd34988806 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -614,6 +614,7 @@ VIR_ENUM_IMPL(virQEMUCaps, /* 390 */ "vhost-user-blk", + "memory-backend-file.x-use-canonical-path-for-ramblock-id", ); @@ -1682,6 +1683,11 @@ static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsMemoryBackendFile[] = { "discard-data", QEMU_CAPS_OBJECT_MEMORY_FILE_DISCARD }, { "align", QEMU_CAPS_OBJECT_MEMORY_FILE_ALIGN }, { "pmem", QEMU_CAPS_OBJECT_MEMORY_FILE_PMEM }, + /* As of QEMU commit 8db0b20415c129cf5e577a593a4a0372d90b7cc9 the + * "x-use-canonical-path-for-ramblock-id" property is considered stable and + * supported. The 'x-' prefix was kept for compatibility with already + * released qemu versions. */ + { "x-use-canonical-path-for-ramblock-id", QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID }, }; static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsMemoryBackendMemfd[] = { diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h index 8cb5673042..c422636d3a 100644 --- a/src/qemu/qemu_capabilities.h +++ b/src/qemu/qemu_capabilities.h @@ -594,6 +594,7 @@ typedef enum { /* virQEMUCapsFlags grouping marker for syntax-check */ /* 390 */ QEMU_CAPS_DEVICE_VHOST_USER_BLK, /* -device vhost-user-blk */ + QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID, /* -object memory-backend-file,x-use-canonical-path-for-ramblock-id= */ QEMU_CAPS_LAST /* this must always be the last item */ } virQEMUCapsFlags; diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml b/tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml index c28ada94fb..5e7761851f 100644 --- a/tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml +++ b/tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml @@ -181,6 +181,7 @@ <flag name='dc390'/> <flag name='am53c974'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>4000000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>61700240</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml b/tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml index a15edd87de..1d67935bd8 100644 --- a/tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml +++ b/tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml @@ -189,6 +189,7 @@ <flag name='dc390'/> <flag name='am53c974'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>4000000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>42900240</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml b/tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml index de2b578b82..d56a19e6f9 100644 --- a/tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml +++ b/tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml @@ -182,6 +182,7 @@ <flag name='dc390'/> <flag name='am53c974'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>4000000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>0</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml b/tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml index 754ad6db53..d35cb7e2ca 100644 --- a/tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml +++ b/tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml @@ -182,6 +182,7 @@ <flag name='dc390'/> <flag name='am53c974'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>4000000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>0</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.s390x.xml b/tests/qemucapabilitiesdata/caps_4.0.0.s390x.xml index 4a10deea01..ca9592ea11 100644 --- a/tests/qemucapabilitiesdata/caps_4.0.0.s390x.xml +++ b/tests/qemucapabilitiesdata/caps_4.0.0.s390x.xml @@ -145,6 +145,7 @@ <flag name='migration-param.xbzrle-cache-size'/> <flag name='fsdev.createmode'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>4000000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>39100240</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.xml b/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.xml index c580d29374..9f485b317a 100644 --- a/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.xml +++ b/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.xml @@ -226,6 +226,7 @@ <flag name='dc390'/> <flag name='am53c974'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>4000000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>43100240</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_4.1.0.x86_64.xml b/tests/qemucapabilitiesdata/caps_4.1.0.x86_64.xml index 26eb3786e8..04af0a29c3 100644 --- a/tests/qemucapabilitiesdata/caps_4.1.0.x86_64.xml +++ b/tests/qemucapabilitiesdata/caps_4.1.0.x86_64.xml @@ -233,6 +233,7 @@ <flag name='am53c974'/> <flag name='virtio-pmem-pci'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>4001000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>43100241</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_4.2.0.aarch64.xml b/tests/qemucapabilitiesdata/caps_4.2.0.aarch64.xml index 4c149e79bb..863a6e0106 100644 --- a/tests/qemucapabilitiesdata/caps_4.2.0.aarch64.xml +++ b/tests/qemucapabilitiesdata/caps_4.2.0.aarch64.xml @@ -194,6 +194,7 @@ <flag name='dc390'/> <flag name='am53c974'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>4001050</version> <kvmVersion>0</kvmVersion> <microcodeVersion>61700242</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml b/tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml index a0019f2a20..4a079183af 100644 --- a/tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml +++ b/tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml @@ -195,6 +195,7 @@ <flag name='dc390'/> <flag name='am53c974'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>4001050</version> <kvmVersion>0</kvmVersion> <microcodeVersion>42900242</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_4.2.0.s390x.xml b/tests/qemucapabilitiesdata/caps_4.2.0.s390x.xml index 41db85be6b..ffb6f07862 100644 --- a/tests/qemucapabilitiesdata/caps_4.2.0.s390x.xml +++ b/tests/qemucapabilitiesdata/caps_4.2.0.s390x.xml @@ -156,6 +156,7 @@ <flag name='blockdev-hostdev-scsi'/> <flag name='fsdev.createmode'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>4002000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>39100242</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_4.2.0.x86_64.xml b/tests/qemucapabilitiesdata/caps_4.2.0.x86_64.xml index 976eaf347b..e17c7093e2 100644 --- a/tests/qemucapabilitiesdata/caps_4.2.0.x86_64.xml +++ b/tests/qemucapabilitiesdata/caps_4.2.0.x86_64.xml @@ -242,6 +242,7 @@ <flag name='am53c974'/> <flag name='virtio-pmem-pci'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>4002000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>43100242</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_5.0.0.aarch64.xml b/tests/qemucapabilitiesdata/caps_5.0.0.aarch64.xml index b9963bbd7e..3373cfc69e 100644 --- a/tests/qemucapabilitiesdata/caps_5.0.0.aarch64.xml +++ b/tests/qemucapabilitiesdata/caps_5.0.0.aarch64.xml @@ -204,6 +204,7 @@ <flag name='dc390'/> <flag name='am53c974'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>5000000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>61700241</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml b/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml index 46edacd44b..1e4c90653c 100644 --- a/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml +++ b/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml @@ -213,6 +213,7 @@ <flag name='dc390'/> <flag name='am53c974'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>5000000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>42900241</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_5.0.0.riscv64.xml b/tests/qemucapabilitiesdata/caps_5.0.0.riscv64.xml index 496b75da20..7a27dd75d9 100644 --- a/tests/qemucapabilitiesdata/caps_5.0.0.riscv64.xml +++ b/tests/qemucapabilitiesdata/caps_5.0.0.riscv64.xml @@ -200,6 +200,7 @@ <flag name='dc390'/> <flag name='am53c974'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>5000000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>0</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml b/tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml index f5bcc9ed83..9e50ede408 100644 --- a/tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml +++ b/tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml @@ -249,6 +249,7 @@ <flag name='am53c974'/> <flag name='virtio-pmem-pci'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>5000000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>43100241</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_5.1.0.sparc.xml b/tests/qemucapabilitiesdata/caps_5.1.0.sparc.xml index a293437850..704ca704e0 100644 --- a/tests/qemucapabilitiesdata/caps_5.1.0.sparc.xml +++ b/tests/qemucapabilitiesdata/caps_5.1.0.sparc.xml @@ -115,6 +115,7 @@ <flag name='netdev.vhost-vdpa'/> <flag name='fsdev.createmode'/> <flag name='ncr53c90'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>5001000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>0</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml b/tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml index f7d0be69cb..2044e197a3 100644 --- a/tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml +++ b/tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml @@ -251,6 +251,7 @@ <flag name='am53c974'/> <flag name='virtio-pmem-pci'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>5001000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>43100242</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_5.2.0.aarch64.xml b/tests/qemucapabilitiesdata/caps_5.2.0.aarch64.xml index 6b40141f15..a32f18d4f2 100644 --- a/tests/qemucapabilitiesdata/caps_5.2.0.aarch64.xml +++ b/tests/qemucapabilitiesdata/caps_5.2.0.aarch64.xml @@ -208,6 +208,7 @@ <flag name='dc390'/> <flag name='am53c974'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>5002000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>61700243</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_5.2.0.ppc64.xml b/tests/qemucapabilitiesdata/caps_5.2.0.ppc64.xml index 298139cdd7..a26b19e78e 100644 --- a/tests/qemucapabilitiesdata/caps_5.2.0.ppc64.xml +++ b/tests/qemucapabilitiesdata/caps_5.2.0.ppc64.xml @@ -215,6 +215,7 @@ <flag name='dc390'/> <flag name='am53c974'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>5002000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>42900243</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_5.2.0.riscv64.xml b/tests/qemucapabilitiesdata/caps_5.2.0.riscv64.xml index 0457018c93..9eaccb2089 100644 --- a/tests/qemucapabilitiesdata/caps_5.2.0.riscv64.xml +++ b/tests/qemucapabilitiesdata/caps_5.2.0.riscv64.xml @@ -202,6 +202,7 @@ <flag name='dc390'/> <flag name='am53c974'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>5002000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>0</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml b/tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml index b59404230c..3891c9e0dd 100644 --- a/tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml +++ b/tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml @@ -163,6 +163,7 @@ <flag name='netdev.vhost-vdpa'/> <flag name='fsdev.createmode'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>5002000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>39100243</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml b/tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml index 52a755ffc8..01409003d1 100644 --- a/tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml +++ b/tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml @@ -252,6 +252,7 @@ <flag name='am53c974'/> <flag name='virtio-pmem-pci'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>5002000</version> <kvmVersion>0</kvmVersion> <microcodeVersion>43100243</microcodeVersion> diff --git a/tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml b/tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml index fcc416206c..515a79232e 100644 --- a/tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml +++ b/tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml @@ -253,6 +253,7 @@ <flag name='virtio-pmem-pci'/> <flag name='vhost-user-fs.bootindex'/> <flag name='vhost-user-blk'/> + <flag name='memory-backend-file.x-use-canonical-path-for-ramblock-id'/> <version>5002050</version> <kvmVersion>0</kvmVersion> <microcodeVersion>43100242</microcodeVersion> -- 2.26.2

On Wed, Feb 10, 2021 at 14:38:13 +0100, Michal Privoznik wrote:
This capability tracks whether memory-backend-file has "x-use-canonical-path-for-ramblock-id" attribute. Introduced into QEMU by commit fa0cb34d2210cc749b9a70db99bb41c56ad20831. As of QEMU commit 8db0b20415c129cf5e577a593a4a0372d90b7cc9 the property is considered stable by qemu despite the 'x-' prefix to preserve compatibility with released qemu versions.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> ---
Reviewed-by: Peter Krempa <pkrempa@redhat.com>

In commit 88957116c9d3cb4705380c3702c9d4315fb500bb I've adapted libvirt to QEMU's deprecation of -mem-path and -mem-prealloc and switched to memory-backend-* even for system memory. My claim was that that's what QEMU does under the hood anyway. And indeed it was: see QEMU commit 900c0ba373aada4c13d47d95330aa72ec4067ba5 and look at function create_default_memdev(). However, then commit d96c4d5f193e0e45beec80a6277728b32875bddb was merged into QEMU. While it was fixing a bug, it also changed the create_default_memdev() function in which it started turning off use of canonical path (by setting "x-use-canonical-path-for-ramblock-id" attribute to false). This wasn't documented until QEMU commit XXX. The path affects migration - the same path has to be used on the source and on the destination. Therefore, if there is old guest started with '-m X' it has "pc.ram" block which doesn't use canonical path and thus when migrating to newer QEMU which uses memory-backend-* we have to turn off the canonical path explicitly. Otherwise, "/objects/pc.ram" path would be expected by QEMU which doesn't match the source. Ideally, we would need to set it only for some machine types (4.0 and older) because newer machine types already do what we are doing. However, we treat machine types as opaque strings and therefore we don't want to parse nor inspect their versions. But then again, newer machine types already do what we are doing in this commit, so when old machine types are deprecated and removed we can remove our hack and forget it ever happened. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1912201 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- src/qemu/qemu_command.c | 35 ++++++++++++++++--- src/qemu/qemu_command.h | 3 +- src/qemu/qemu_hotplug.c | 2 +- .../disk-vhostuser.x86_64-latest.args | 3 +- .../hugepages-memaccess3.x86_64-latest.args | 4 +-- 5 files changed, 38 insertions(+), 9 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 92036d26c0..699d89de1d 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -2975,7 +2975,8 @@ qemuBuildMemoryBackendProps(virJSONValuePtr *backendProps, qemuDomainObjPrivatePtr priv, const virDomainDef *def, const virDomainMemoryDef *mem, - bool force) + bool force, + bool systemMemory) { const char *backendType = "memory-backend-file"; virDomainNumatuneMemMode mode; @@ -2992,6 +2993,10 @@ qemuBuildMemoryBackendProps(virJSONValuePtr *backendProps, bool needHugepage = !!pagesize; bool useHugepage = !!pagesize; int discard = mem->discard; + bool disableCanonicalPath = false; + + /* Disabling canonical path is required for migration compatibility of + * system memory objects, see below */ /* The difference between @needHugepage and @useHugepage is that the latter * is true whenever huge page is defined for the current memory cell. @@ -3106,6 +3111,9 @@ qemuBuildMemoryBackendProps(virJSONValuePtr *backendProps, if (qemuBuildMemoryBackendPropsShare(props, memAccess) < 0) return -1; + if (systemMemory) + disableCanonicalPath = true; + } else if (useHugepage || mem->nvdimmPath || memAccess || def->mem.source == VIR_DOMAIN_MEMORY_SOURCE_FILE) { @@ -3148,10 +3156,29 @@ qemuBuildMemoryBackendProps(virJSONValuePtr *backendProps, if (qemuBuildMemoryBackendPropsShare(props, memAccess) < 0) return -1; + + if (systemMemory) + disableCanonicalPath = true; + } else { backendType = "memory-backend-ram"; } + /* This is a terrible hack, but unfortunately there is no better way. + * The replacement for '-m X' argument is not simple '-machine + * memory-backend' and '-object memory-backend-*,size=X' (which was the + * idea). This is because of create_default_memdev() in QEMU sets + * 'x-use-canonical-path-for-ramblock-id' attribute to false and is + * documented in QEMU in qemu-options.hx under 'memory-backend'. Note + * that QEMU consideres 'x-use-canonical-path-for-ramblock-id' stable + * and supported despite the 'x-' prefix. + * See QEMU commit 8db0b20415c129cf5e577a593a4a0372d90b7cc9. + */ + if (disableCanonicalPath && + virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID) && + virJSONValueObjectAdd(props, "b:x-use-canonical-path-for-ramblock-id", false, NULL) < 0) + return -1; + if (!priv->memPrealloc && virJSONValueObjectAdd(props, "B:prealloc", prealloc, NULL) < 0) return -1; @@ -3263,7 +3290,7 @@ qemuBuildMemoryCellBackendStr(virDomainDefPtr def, mem.info.alias = alias; if ((rc = qemuBuildMemoryBackendProps(&props, alias, cfg, - priv, def, &mem, false)) < 0) + priv, def, &mem, false, false)) < 0) return -1; if (virQEMUBuildObjectCommandlineFromJSON(buf, props) < 0) @@ -3292,7 +3319,7 @@ qemuBuildMemoryDimmBackendStr(virBufferPtr buf, alias = g_strdup_printf("mem%s", mem->info.alias); if (qemuBuildMemoryBackendProps(&props, alias, cfg, - priv, def, mem, true) < 0) + priv, def, mem, true, false) < 0) return -1; if (virQEMUBuildObjectCommandlineFromJSON(buf, props) < 0) @@ -7100,7 +7127,7 @@ qemuBuildMemCommandLineMemoryDefaultBackend(virCommandPtr cmd, mem.info.alias = (char *) defaultRAMid; if (qemuBuildMemoryBackendProps(&props, defaultRAMid, cfg, - priv, def, &mem, false) < 0) + priv, def, &mem, false, true) < 0) return -1; if (virQEMUBuildObjectCommandlineFromJSON(&buf, props) < 0) diff --git a/src/qemu/qemu_command.h b/src/qemu/qemu_command.h index a33fbf6f4e..bdae117e02 100644 --- a/src/qemu/qemu_command.h +++ b/src/qemu/qemu_command.h @@ -161,7 +161,8 @@ int qemuBuildMemoryBackendProps(virJSONValuePtr *backendProps, qemuDomainObjPrivatePtr priv, const virDomainDef *def, const virDomainMemoryDef *mem, - bool force); + bool force, + bool systemMemory); char * qemuBuildMemoryDeviceStr(const virDomainDef *def, diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index dc2b46057c..e7863328db 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -2430,7 +2430,7 @@ qemuDomainAttachMemory(virQEMUDriverPtr driver, goto cleanup; if (qemuBuildMemoryBackendProps(&props, objalias, cfg, - priv, vm->def, mem, true) < 0) + priv, vm->def, mem, true, false) < 0) goto cleanup; if (qemuProcessBuildDestroyMemoryPaths(driver, vm, mem, true) < 0) diff --git a/tests/qemuxml2argvdata/disk-vhostuser.x86_64-latest.args b/tests/qemuxml2argvdata/disk-vhostuser.x86_64-latest.args index 30acd7c78b..9ee855d5c7 100644 --- a/tests/qemuxml2argvdata/disk-vhostuser.x86_64-latest.args +++ b/tests/qemuxml2argvdata/disk-vhostuser.x86_64-latest.args @@ -15,7 +15,8 @@ file=/tmp/lib/domain--1-QEMUGuest1/master-key.aes \ -machine pc,accel=tcg,usb=off,dump-guest-core=off,memory-backend=pc.ram \ -cpu qemu64 \ -m 214 \ --object memory-backend-memfd,id=pc.ram,share=yes,size=224395264 \ +-object memory-backend-memfd,id=pc.ram,share=yes,\ +x-use-canonical-path-for-ramblock-id=no,size=224395264 \ -overcommit mem-lock=off \ -smp 1,sockets=1,cores=1,threads=1 \ -uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \ diff --git a/tests/qemuxml2argvdata/hugepages-memaccess3.x86_64-latest.args b/tests/qemuxml2argvdata/hugepages-memaccess3.x86_64-latest.args index 6033950eab..9396441b92 100644 --- a/tests/qemuxml2argvdata/hugepages-memaccess3.x86_64-latest.args +++ b/tests/qemuxml2argvdata/hugepages-memaccess3.x86_64-latest.args @@ -19,8 +19,8 @@ arch-capabilities=on,ssbd=on,xsaves=on,cmp-legacy=on,amd-ssbd=on,virt-ssbd=on,\ rdctl-no=on,skip-l1dfl-vmentry=on,mds-no=on,pschange-mc-no=on \ -m 4096 \ -object memory-backend-file,id=pc.ram,\ -mem-path=/dev/hugepages2M/libvirt/qemu/-1-fedora,share=yes,prealloc=yes,\ -size=4294967296 \ +mem-path=/dev/hugepages2M/libvirt/qemu/-1-fedora,share=yes,\ +x-use-canonical-path-for-ramblock-id=no,prealloc=yes,size=4294967296 \ -overcommit mem-lock=off \ -smp 4,sockets=4,cores=1,threads=1 \ -uuid 63840878-0deb-4095-97e6-fc444d9bc9fa \ -- 2.26.2

On Wed, Feb 10, 2021 at 14:38:14 +0100, Michal Privoznik wrote:
In commit 88957116c9d3cb4705380c3702c9d4315fb500bb I've adapted libvirt to QEMU's deprecation of -mem-path and -mem-prealloc and switched to memory-backend-* even for system memory. My claim was that that's what QEMU does under the hood anyway. And indeed it was: see QEMU commit 900c0ba373aada4c13d47d95330aa72ec4067ba5 and look at function create_default_memdev().
However, then commit d96c4d5f193e0e45beec80a6277728b32875bddb was merged into QEMU. While it was fixing a bug, it also changed the create_default_memdev() function in which it started turning off use of canonical path (by setting "x-use-canonical-path-for-ramblock-id" attribute to false). This wasn't documented until QEMU commit XXX. The path affects
s/XXX/actual commit id/
migration - the same path has to be used on the source and on the destination. Therefore, if there is old guest started with '-m X' it has "pc.ram" block which doesn't use canonical path and thus when migrating to newer QEMU which uses memory-backend-* we have to turn off the canonical path explicitly. Otherwise, "/objects/pc.ram" path would be expected by QEMU which doesn't match the source.
Ideally, we would need to set it only for some machine types (4.0 and older) because newer machine types already do what we are doing. However, we treat machine types as opaque strings and therefore we don't want to parse nor inspect their versions. But then again, newer machine types already do what we are doing in this commit, so when old machine types are deprecated and removed we can remove our hack and forget it ever happened.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1912201 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- src/qemu/qemu_command.c | 35 ++++++++++++++++--- src/qemu/qemu_command.h | 3 +- src/qemu/qemu_hotplug.c | 2 +- .../disk-vhostuser.x86_64-latest.args | 3 +- .../hugepages-memaccess3.x86_64-latest.args | 4 +-- 5 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 92036d26c0..699d89de1d 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c
[...]
@@ -3148,10 +3156,29 @@ qemuBuildMemoryBackendProps(virJSONValuePtr *backendProps,
if (qemuBuildMemoryBackendPropsShare(props, memAccess) < 0) return -1; + + if (systemMemory) + disableCanonicalPath = true; + } else { backendType = "memory-backend-ram"; }
+ /* This is a terrible hack, but unfortunately there is no better way. + * The replacement for '-m X' argument is not simple '-machine + * memory-backend' and '-object memory-backend-*,size=X' (which was the + * idea). This is because of create_default_memdev() in QEMU sets + * 'x-use-canonical-path-for-ramblock-id' attribute to false and is + * documented in QEMU in qemu-options.hx under 'memory-backend'. Note + * that QEMU consideres 'x-use-canonical-path-for-ramblock-id' stable + * and supported despite the 'x-' prefix. + * See QEMU commit 8db0b20415c129cf5e577a593a4a0372d90b7cc9. + */ + if (disableCanonicalPath && + virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID) && + virJSONValueObjectAdd(props, "b:x-use-canonical-path-for-ramblock-id", false, NULL) < 0) + return -1;
I don't remember whether you and Daniel reached some consensus about the machine type version check, but if the consensus is to always output it then okay.
From my side:
Reviewed-by: Peter Krempa <pkrempa@redhat.com>

On 2/10/21 5:10 PM, Peter Krempa wrote:
On Wed, Feb 10, 2021 at 14:38:14 +0100, Michal Privoznik wrote:
In commit 88957116c9d3cb4705380c3702c9d4315fb500bb I've adapted libvirt to QEMU's deprecation of -mem-path and -mem-prealloc and switched to memory-backend-* even for system memory. My claim was that that's what QEMU does under the hood anyway. And indeed it was: see QEMU commit 900c0ba373aada4c13d47d95330aa72ec4067ba5 and look at function create_default_memdev().
However, then commit d96c4d5f193e0e45beec80a6277728b32875bddb was merged into QEMU. While it was fixing a bug, it also changed the create_default_memdev() function in which it started turning off use of canonical path (by setting "x-use-canonical-path-for-ramblock-id" attribute to false). This wasn't documented until QEMU commit XXX. The path affects
s/XXX/actual commit id/
migration - the same path has to be used on the source and on the destination. Therefore, if there is old guest started with '-m X' it has "pc.ram" block which doesn't use canonical path and thus when migrating to newer QEMU which uses memory-backend-* we have to turn off the canonical path explicitly. Otherwise, "/objects/pc.ram" path would be expected by QEMU which doesn't match the source.
Ideally, we would need to set it only for some machine types (4.0 and older) because newer machine types already do what we are doing. However, we treat machine types as opaque strings and therefore we don't want to parse nor inspect their versions. But then again, newer machine types already do what we are doing in this commit, so when old machine types are deprecated and removed we can remove our hack and forget it ever happened.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1912201 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- src/qemu/qemu_command.c | 35 ++++++++++++++++--- src/qemu/qemu_command.h | 3 +- src/qemu/qemu_hotplug.c | 2 +- .../disk-vhostuser.x86_64-latest.args | 3 +- .../hugepages-memaccess3.x86_64-latest.args | 4 +-- 5 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 92036d26c0..699d89de1d 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c
[...]
@@ -3148,10 +3156,29 @@ qemuBuildMemoryBackendProps(virJSONValuePtr *backendProps,
if (qemuBuildMemoryBackendPropsShare(props, memAccess) < 0) return -1; + + if (systemMemory) + disableCanonicalPath = true; + } else { backendType = "memory-backend-ram"; }
+ /* This is a terrible hack, but unfortunately there is no better way. + * The replacement for '-m X' argument is not simple '-machine + * memory-backend' and '-object memory-backend-*,size=X' (which was the + * idea). This is because of create_default_memdev() in QEMU sets + * 'x-use-canonical-path-for-ramblock-id' attribute to false and is + * documented in QEMU in qemu-options.hx under 'memory-backend'. Note + * that QEMU consideres 'x-use-canonical-path-for-ramblock-id' stable + * and supported despite the 'x-' prefix. + * See QEMU commit 8db0b20415c129cf5e577a593a4a0372d90b7cc9. + */ + if (disableCanonicalPath && + virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID) && + virJSONValueObjectAdd(props, "b:x-use-canonical-path-for-ramblock-id", false, NULL) < 0) + return -1;
I don't remember whether you and Daniel reached some consensus about the machine type version check, but if the consensus is to always output it then okay.
Yeah, this is the consensus. The reason is that distros may introduce their own machine types with version appearing at unexpected place (or not appearing at all). Also, finding an ordering function is not trivial and we also would need to know which machine types have the feature turned on/off by default. Since QEMU claims it is safe to turn the feature off at all times, let's not bother with parsing anything and just turn it off always.
From my side:
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Thanks, pushed. Michal

On 2/10/21 2:38 PM, Michal Privoznik wrote:
v3 of:
https://listman.redhat.com/archives/libvir-list/2021-January/msg00684.html
diff to v2: - Rebased as new capabilities and capabilities files were added since v2
Huh, except meanwhile another commits were pushed which create conflict. I've pushed updated commits into my gitlab: https://gitlab.com/MichalPrivoznik/libvirt/-/commits/qemu_machine_memory_bac... Michal
participants (2)
-
Michal Privoznik
-
Peter Krempa