From 3d3c853368373dba5895d9c470e7f3bdb5381751 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Wed, 16 Sep 2020 15:53:57 +0800 Subject: [PATCH 01/44] tests/commandtest: skip the test4 if the testcase is run in the container env In a container environment without an init thread, the daemoned process is not reclaimed, and Test4 loops forever, causing the compilation to hung. So, skip it. Signed-off-by: AlexChen --- ...t-skip-the-test4-if-the-testcase-is-.patch | 47 +++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 tests-commandtest-skip-the-test4-if-the-testcase-is-.patch diff --git a/tests-commandtest-skip-the-test4-if-the-testcase-is-.patch b/tests-commandtest-skip-the-test4-if-the-testcase-is-.patch new file mode 100644 index 0000000..be63b80 --- /dev/null +++ b/tests-commandtest-skip-the-test4-if-the-testcase-is-.patch @@ -0,0 +1,47 @@ +From 0b6e5773058e85b8e5e6ce83d3b275726e6883f2 Mon Sep 17 00:00:00 2001 +From: AlexChen +Date: Wed, 16 Sep 2020 15:53:57 +0800 +Subject: [PATCH] tests/commandtest: skip the test4 if the testcase is run in + the container env + +In a container environment without an init thread, the daemoned +process is not reclaimed, and Test4 loops forever, causing +the compilation to hung. So, skip it. + +Signed-off-by: AlexChen +--- + tests/commandtest.c | 11 ++++++++--- + 1 file changed, 8 insertions(+), 3 deletions(-) + +diff --git a/tests/commandtest.c b/tests/commandtest.c +index d5092b7dd0..ce492e31f7 100644 +--- a/tests/commandtest.c ++++ b/tests/commandtest.c +@@ -259,6 +259,7 @@ static int test4(const void *unused G_GNUC_UNUSED) + char *pidfile = virPidFileBuildPath(abs_builddir, "commandhelper"); + pid_t pid; + int ret = -1; ++ int count = 0; + + if (!pidfile) + goto cleanup; +@@ -275,9 +276,13 @@ static int test4(const void *unused G_GNUC_UNUSED) + printf("cannot read pidfile\n"); + goto cleanup; + } +- while (kill(pid, 0) != -1) +- g_usleep(100*1000); +- ++ while (kill(pid, 0) != -1) { ++ if (count++ >= 600) { ++ printf("check time exceeds 60s, it may be in container env, skip this testcase!!!\n"); ++ break; ++ } ++ g_usleep(100*1000); /* 100 */ ++ } + ret = checkoutput("test4", NULL); + + cleanup: +-- +2.23.0 + -- Gitee From 88831e080cadcdd782b2b66e0467a138541a9709 Mon Sep 17 00:00:00 2001 From: Euler Robot Date: Mon, 26 Oct 2020 20:41:08 +0800 Subject: [PATCH 02/44] spec: Update patch and changelog with !2 tests/commandtest: skip the test4 if the testcase is run in the container env Signed-off-by: AlexChen --- libvirt.spec | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/libvirt.spec b/libvirt.spec index bc5e82f..9438ccc 100644 --- a/libvirt.spec +++ b/libvirt.spec @@ -164,6 +164,7 @@ Patch0053: qemuDomainDefPostParse-Fail-if-unable-to-fill-machin.patch Patch0054: virNetDevGetFamilyId-Change-signature.patch Patch0055: virNetDevSwitchdevFeature-Make-failure-to-get-family.patch Patch0056: qemuDomainGetUnplugTimeout-Add-G_GNUC_NO_INLINE.patch +Patch0057: tests-commandtest-skip-the-test4-if-the-testcase-is-.patch Requires: libvirt-daemon = %{version}-%{release} Requires: libvirt-daemon-config-network = %{version}-%{release} @@ -1896,6 +1897,9 @@ exit 0 %changelog +* Wed Sep 16 2020 Huawei Technologies Co., Ltd +- tests/commandtest: skip the test4 if the testcase is run in the container env + * Tue Sep 22 2020 AlexChen - 6.2.0-13 - bugfix: cherry-pick some bugfix patches from opensource community * Tue Sep 22 2020 Hao Wang - 6.2.0-12 -- Gitee From 31d064c981b2f137b3537edf3f459e579190e023 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Tue, 4 Aug 2020 01:44:48 +0000 Subject: [PATCH 03/44] Substitute security_context_t with char * Historically, we've used security_context_t for variables passed to libselinux APIs. But almost 7 years ago, libselinux developers admitted in their API that in fact, it's just a 'char *' type [1]. Ever since then the APIs accept 'char *' instead, but they kept the old alias just for API stability. Well, not anymore [2]. 1: https://github.com/SELinuxProject/selinux/commit/9eb9c9327563014ad6a807814e7975424642d5b9 2: https://github.com/SELinuxProject/selinux/commit/7a124ca2758136f49cc38efc26fb1a2d385ecfd9 Signed-off-by: Michal Privoznik Reviewed-by: Andrea Bolognani (cherry-picked from commit e71e13488dc1aa65456e54a4b41bc925821b4263) Signed-off-by: Xu Yandong --- Substitute-security_context_t-with-char.patch | 320 ++++++++++++++++++ 1 file changed, 320 insertions(+) create mode 100644 Substitute-security_context_t-with-char.patch diff --git a/Substitute-security_context_t-with-char.patch b/Substitute-security_context_t-with-char.patch new file mode 100644 index 0000000..77a26aa --- /dev/null +++ b/Substitute-security_context_t-with-char.patch @@ -0,0 +1,320 @@ +From dc5bfcec3c97d7cc065483a7a567e64ed805edb4 Mon Sep 17 00:00:00 2001 +From: Xu Yandong +Date: Tue, 4 Aug 2020 01:44:48 +0000 +Subject: [PATCH] Substitute security_context_t with char * + +Historically, we've used security_context_t for variables passed +to libselinux APIs. But almost 7 years ago, libselinux developers +admitted in their API that in fact, it's just a 'char *' type +[1]. Ever since then the APIs accept 'char *' instead, but they +kept the old alias just for API stability. Well, not anymore [2]. + +1: https://github.com/SELinuxProject/selinux/commit/9eb9c9327563014ad6a807814e7975424642d5b9 +2: https://github.com/SELinuxProject/selinux/commit/7a124ca2758136f49cc38efc26fb1a2d385ecfd9 + +Signed-off-by: Michal Privoznik +Reviewed-by: Andrea Bolognani +(cherry-picked from commit e71e13488dc1aa65456e54a4b41bc925821b4263) +Signed-off-by: Xu Yandong +--- + src/libvirt-lxc.c | 2 +- + src/rpc/virnetsocket.c | 2 +- + src/security/security_selinux.c | 26 +++++++++++++------------- + src/storage/storage_util.c | 2 +- + src/util/viridentity.c | 2 +- + tests/securityselinuxhelper.c | 16 ++++++++-------- + tests/securityselinuxlabeltest.c | 4 ++-- + tests/securityselinuxtest.c | 2 +- + tests/viridentitytest.c | 2 +- + 9 files changed, 29 insertions(+), 29 deletions(-) + +diff --git a/src/libvirt-lxc.c b/src/libvirt-lxc.c +index 47a06a39f2..25f1cfc5f7 100644 +--- a/src/libvirt-lxc.c ++++ b/src/libvirt-lxc.c +@@ -204,7 +204,7 @@ virDomainLxcEnterSecurityLabel(virSecurityModelPtr model, + if (STREQ(model->model, "selinux")) { + #ifdef WITH_SELINUX + if (oldlabel) { +- security_context_t ctx; ++ char *ctx; + + if (getcon(&ctx) < 0) { + virReportSystemError(errno, +diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c +index 6c790cb577..553728984b 100644 +--- a/src/rpc/virnetsocket.c ++++ b/src/rpc/virnetsocket.c +@@ -1595,7 +1595,7 @@ int virNetSocketGetUNIXIdentity(virNetSocketPtr sock G_GNUC_UNUSED, + int virNetSocketGetSELinuxContext(virNetSocketPtr sock, + char **context) + { +- security_context_t seccon = NULL; ++ char *seccon = NULL; + int ret = -1; + + *context = NULL; +diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c +index 8aeb6e45a5..72d1658e05 100644 +--- a/src/security/security_selinux.c ++++ b/src/security/security_selinux.c +@@ -198,7 +198,7 @@ virSecuritySELinuxTransactionAppend(const char *path, + + static int + virSecuritySELinuxRememberLabel(const char *path, +- const security_context_t con) ++ const char *con) + { + return virSecuritySetRememberedLabel(SECURITY_SELINUX_NAME, + path, con); +@@ -207,7 +207,7 @@ virSecuritySELinuxRememberLabel(const char *path, + + static int + virSecuritySELinuxRecallLabel(const char *path, +- security_context_t *con) ++ char **con) + { + int rv; + +@@ -431,7 +431,7 @@ virSecuritySELinuxMCSGetProcessRange(char **sens, + int *catMin, + int *catMax) + { +- security_context_t ourSecContext = NULL; ++ char *ourSecContext = NULL; + context_t ourContext = NULL; + char *cat = NULL; + char *tmp; +@@ -530,8 +530,8 @@ virSecuritySELinuxMCSGetProcessRange(char **sens, + } + + static char * +-virSecuritySELinuxContextAddRange(security_context_t src, +- security_context_t dst) ++virSecuritySELinuxContextAddRange(char *src, ++ char *dst) + { + char *str = NULL; + char *ret = NULL; +@@ -575,7 +575,7 @@ virSecuritySELinuxGenNewContext(const char *basecontext, + context_t context = NULL; + char *ret = NULL; + char *str; +- security_context_t ourSecContext = NULL; ++ char *ourSecContext = NULL; + context_t ourContext = NULL; + + VIR_DEBUG("basecontext=%s mcs=%s isObjectContext=%d", +@@ -967,7 +967,7 @@ virSecuritySELinuxReserveLabel(virSecurityManagerPtr mgr, + virDomainDefPtr def, + pid_t pid) + { +- security_context_t pctx; ++ char *pctx; + context_t ctx = NULL; + const char *mcs; + int rv; +@@ -1217,7 +1217,7 @@ virSecuritySELinuxGetProcessLabel(virSecurityManagerPtr mgr G_GNUC_UNUSED, + pid_t pid, + virSecurityLabelPtr sec) + { +- security_context_t ctx; ++ char *ctx; + + if (getpidcon_raw(pid, &ctx) == -1) { + virReportSystemError(errno, +@@ -1330,7 +1330,7 @@ virSecuritySELinuxSetFilecon(virSecurityManagerPtr mgr, + bool remember) + { + bool privileged = virSecurityManagerGetPrivileged(mgr); +- security_context_t econ = NULL; ++ char *econ = NULL; + int refcount; + int rc; + bool rollback = false; +@@ -1440,7 +1440,7 @@ virSecuritySELinuxFSetFilecon(int fd, char *tcon) + /* Set fcon to the appropriate label for path and mode, or return -1. */ + static int + getContext(virSecurityManagerPtr mgr G_GNUC_UNUSED, +- const char *newpath, mode_t mode, security_context_t *fcon) ++ const char *newpath, mode_t mode, char **fcon) + { + virSecuritySELinuxDataPtr data = virSecurityManagerGetPrivateData(mgr); + +@@ -1457,7 +1457,7 @@ virSecuritySELinuxRestoreFileLabel(virSecurityManagerPtr mgr, + { + bool privileged = virSecurityManagerGetPrivileged(mgr); + struct stat buf; +- security_context_t fcon = NULL; ++ char *fcon = NULL; + char *newpath = NULL; + int rc; + int ret = -1; +@@ -2972,7 +2972,7 @@ virSecuritySELinuxSetDaemonSocketLabel(virSecurityManagerPtr mgr G_GNUC_UNUSED, + { + /* TODO: verify DOI */ + virSecurityLabelDefPtr secdef; +- security_context_t scon = NULL; ++ char *scon = NULL; + char *str = NULL; + int rc = -1; + +@@ -3259,7 +3259,7 @@ virSecuritySELinuxSetTapFDLabel(virSecurityManagerPtr mgr, + int fd) + { + struct stat buf; +- security_context_t fcon = NULL; ++ char *fcon = NULL; + virSecurityLabelDefPtr secdef; + char *str = NULL, *proc = NULL, *fd_path = NULL; + int rc = -1; +diff --git a/src/storage/storage_util.c b/src/storage/storage_util.c +index 1ec1d13625..4c67d3a4b1 100644 +--- a/src/storage/storage_util.c ++++ b/src/storage/storage_util.c +@@ -1818,7 +1818,7 @@ virStorageBackendUpdateVolTargetInfoFD(virStorageSourcePtr target, + struct stat *sb) + { + #if WITH_SELINUX +- security_context_t filecon = NULL; ++ char *filecon = NULL; + #endif + + if (virStorageSourceUpdateBackingSizes(target, fd, sb) < 0) +diff --git a/src/util/viridentity.c b/src/util/viridentity.c +index 8cc2db2568..2cb9042a84 100644 +--- a/src/util/viridentity.c ++++ b/src/util/viridentity.c +@@ -157,7 +157,7 @@ virIdentityPtr virIdentityGetSystem(void) + unsigned long long startTime; + g_autoptr(virIdentity) ret = NULL; + #if WITH_SELINUX +- security_context_t con; ++ char *con; + #endif + + if (!(ret = virIdentityNew())) +diff --git a/tests/securityselinuxhelper.c b/tests/securityselinuxhelper.c +index f89224c07a..63b57261da 100644 +--- a/tests/securityselinuxhelper.c ++++ b/tests/securityselinuxhelper.c +@@ -58,7 +58,7 @@ static struct selabel_handle *(*real_selabel_open)(unsigned int backend, + unsigned nopts); + static void (*real_selabel_close)(struct selabel_handle *handle); + static int (*real_selabel_lookup_raw)(struct selabel_handle *handle, +- security_context_t *con, ++ char **con, + const char *key, + int type); + +@@ -94,7 +94,7 @@ static void init_syms(void) + * the virt_use_nfs bool is set. + */ + +-int getcon_raw(security_context_t *context) ++int getcon_raw(char **context) + { + if (!is_selinux_enabled()) { + errno = EINVAL; +@@ -109,12 +109,12 @@ int getcon_raw(security_context_t *context) + return 0; + } + +-int getcon(security_context_t *context) ++int getcon(char **context) + { + return getcon_raw(context); + } + +-int getpidcon_raw(pid_t pid, security_context_t *context) ++int getpidcon_raw(pid_t pid, char **context) + { + if (!is_selinux_enabled()) { + errno = EINVAL; +@@ -134,7 +134,7 @@ int getpidcon_raw(pid_t pid, security_context_t *context) + return 0; + } + +-int getpidcon(pid_t pid, security_context_t *context) ++int getpidcon(pid_t pid, char **context) + { + return getpidcon_raw(pid, context); + } +@@ -170,7 +170,7 @@ int setfilecon(const char *path, const char *con) + return setfilecon_raw(path, con); + } + +-int getfilecon_raw(const char *path, security_context_t *con) ++int getfilecon_raw(const char *path, char **con) + { + char *constr = NULL; + ssize_t len = getxattr(path, "user.libvirt.selinux", +@@ -194,7 +194,7 @@ int getfilecon_raw(const char *path, security_context_t *con) + } + + +-int getfilecon(const char *path, security_context_t *con) ++int getfilecon(const char *path, char **con) + { + return getfilecon_raw(path, con); + } +@@ -315,7 +315,7 @@ void selabel_close(struct selabel_handle *handle) + } + + int selabel_lookup_raw(struct selabel_handle *handle, +- security_context_t *con, ++ char **con, + const char *key, + int type) + { +diff --git a/tests/securityselinuxlabeltest.c b/tests/securityselinuxlabeltest.c +index 3040a36693..50b447c163 100644 +--- a/tests/securityselinuxlabeltest.c ++++ b/tests/securityselinuxlabeltest.c +@@ -252,7 +252,7 @@ static int + testSELinuxCheckLabels(testSELinuxFile *files, size_t nfiles) + { + size_t i; +- security_context_t ctx; ++ char *ctx; + + for (i = 0; i < nfiles; i++) { + ctx = NULL; +@@ -360,7 +360,7 @@ mymain(void) + if (virTestRun("Labelling " # name, testSELinuxLabeling, name) < 0) \ + ret = -1; + +- setcon((security_context_t)"system_r:system_u:libvirtd_t:s0:c0.c1023"); ++ setcon("system_r:system_u:libvirtd_t:s0:c0.c1023"); + + DO_TEST_LABELING("disks"); + DO_TEST_LABELING("kernel"); +diff --git a/tests/securityselinuxtest.c b/tests/securityselinuxtest.c +index 6c8314de6b..3f069c2d6b 100644 +--- a/tests/securityselinuxtest.c ++++ b/tests/securityselinuxtest.c +@@ -217,7 +217,7 @@ testSELinuxGenLabel(const void *opaque) + context_t con = NULL; + context_t imgcon = NULL; + +- if (setcon_raw((security_context_t)data->pidcon) < 0) { ++ if (setcon_raw(data->pidcon) < 0) { + perror("Cannot set process security context"); + return -1; + } +diff --git a/tests/viridentitytest.c b/tests/viridentitytest.c +index 3f87af1c3b..9a8c8914d3 100644 +--- a/tests/viridentitytest.c ++++ b/tests/viridentitytest.c +@@ -120,7 +120,7 @@ static int testIdentityGetSystem(const void *data) + static int testSetFakeSELinuxContext(const void *data G_GNUC_UNUSED) + { + #if WITH_SELINUX +- return setcon_raw((security_context_t)data); ++ return setcon_raw(data); + #else + VIR_DEBUG("libvirt not compiled with SELinux, skipping this test"); + return EXIT_AM_SKIP; +-- +2.23.0 + -- Gitee From f798a3d8a144c5792ce5ef298cbc5c72286204fd Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Tue, 4 Aug 2020 08:40:36 +0000 Subject: [PATCH 04/44] conf: Don't format http cookies unless VIR_DOMAIN_DEF_FORMAT_SECURE is used Starting with 3b076391befc3fe72deb0c244ac6c2b4c100b410 (v6.1.0-122-g3b076391be) we support http cookies. Since they may contain somewhat sensitive information we should not format them into the XML unless VIR_DOMAIN_DEF_FORMAT_SECURE is asserted. Reported-by: Han Han Signed-off-by: Peter Krempa Reviewed-by: Erik Skultety (cherry-picked from commit a5b064bf4b17a9884d7d361733737fb614ad8979) Signed-off-by: Xu Yandong --- ...t-http-cookies-unless-VIR_DOMAIN_DEF.patch | 53 +++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 conf-Don-t-format-http-cookies-unless-VIR_DOMAIN_DEF.patch diff --git a/conf-Don-t-format-http-cookies-unless-VIR_DOMAIN_DEF.patch b/conf-Don-t-format-http-cookies-unless-VIR_DOMAIN_DEF.patch new file mode 100644 index 0000000..81e9d76 --- /dev/null +++ b/conf-Don-t-format-http-cookies-unless-VIR_DOMAIN_DEF.patch @@ -0,0 +1,53 @@ +From 6df0bc6f56a76c20a382b8fe6d0afff1051a4077 Mon Sep 17 00:00:00 2001 +From: Xu Yandong +Date: Tue, 4 Aug 2020 08:40:36 +0000 +Subject: [PATCH] conf: Don't format http cookies unless + VIR_DOMAIN_DEF_FORMAT_SECURE is used + +Starting with 3b076391befc3fe72deb0c244ac6c2b4c100b410 +(v6.1.0-122-g3b076391be) we support http cookies. Since they may contain +somewhat sensitive information we should not format them into the XML +unless VIR_DOMAIN_DEF_FORMAT_SECURE is asserted. + +Reported-by: Han Han +Signed-off-by: Peter Krempa +Reviewed-by: Erik Skultety +(cherry-picked from commit a5b064bf4b17a9884d7d361733737fb614ad8979) +Signed-off-by: Xu Yandong +--- + src/conf/domain_conf.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c +index 914e03c705..cf93a591f4 100644 +--- a/src/conf/domain_conf.c ++++ b/src/conf/domain_conf.c +@@ -24565,11 +24565,15 @@ virDomainSourceDefFormatSeclabel(virBufferPtr buf, + + static void + virDomainDiskSourceFormatNetworkCookies(virBufferPtr buf, +- virStorageSourcePtr src) ++ virStorageSourcePtr src, ++ unsigned int flags) + { + g_auto(virBuffer) childBuf = VIR_BUFFER_INIT_CHILD(buf); + size_t i; + ++ if (!(flags & VIR_DOMAIN_DEF_FORMAT_SECURE)) ++ return; ++ + for (i = 0; i < src->ncookies; i++) { + virBufferEscapeString(&childBuf, "", src->cookies[i]->name); + virBufferEscapeString(&childBuf, "%s\n", src->cookies[i]->value); +@@ -24630,7 +24634,7 @@ virDomainDiskSourceFormatNetwork(virBufferPtr attrBuf, + virTristateBoolTypeToString(src->sslverify)); + } + +- virDomainDiskSourceFormatNetworkCookies(childBuf, src); ++ virDomainDiskSourceFormatNetworkCookies(childBuf, src, flags); + + if (src->readahead) + virBufferAsprintf(childBuf, "\n", src->readahead); +-- +2.23.0 + -- Gitee From fd5c428db6ba60196620cd7fa18b171f79684ed9 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Tue, 4 Aug 2020 09:09:04 +0000 Subject: [PATCH 05/44] virstoragetest: testBackingParse: Use VIR_DOMAIN_DEF_FORMAT_SECURE when formatting xml We want to format even the secure information in tests. Signed-off-by: Peter Krempa Reviewed-by: Erik Skultety (cherry-picked from commit 524de6cc35d3b222f0e940bb0fd027f5482572c5) Signed-off-by: Xu Yandong --- ...estBackingParse-Use-VIR_DOMAIN_DEF_F.patch | 40 +++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 virstoragetest-testBackingParse-Use-VIR_DOMAIN_DEF_F.patch diff --git a/virstoragetest-testBackingParse-Use-VIR_DOMAIN_DEF_F.patch b/virstoragetest-testBackingParse-Use-VIR_DOMAIN_DEF_F.patch new file mode 100644 index 0000000..f623be7 --- /dev/null +++ b/virstoragetest-testBackingParse-Use-VIR_DOMAIN_DEF_F.patch @@ -0,0 +1,40 @@ +From fcb8733275c9e8024175db3be48d0b4c33839b75 Mon Sep 17 00:00:00 2001 +From: rpm-build +Date: Tue, 4 Aug 2020 09:09:04 +0000 +Subject: [PATCH] virstoragetest: testBackingParse: Use + VIR_DOMAIN_DEF_FORMAT_SECURE when formatting xml + +We want to format even the secure information in tests. + +Signed-off-by: Peter Krempa +Reviewed-by: Erik Skultety +(cherry-picked from commit 524de6cc35d3b222f0e940bb0fd027f5482572c5) +Signed-off-by: Xu Yandong +--- + tests/virstoragetest.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/tests/virstoragetest.c b/tests/virstoragetest.c +index 6e8ebeba13..6d2b21c25f 100644 +--- a/tests/virstoragetest.c ++++ b/tests/virstoragetest.c +@@ -594,6 +594,7 @@ testBackingParse(const void *args) + g_autoptr(virStorageSource) src = NULL; + int rc; + int erc = data->rv; ++ unsigned int xmlformatflags = VIR_DOMAIN_DEF_FORMAT_SECURE; + + /* expect failure return code with NULL expected data */ + if (!data->expect) +@@ -613,7 +614,7 @@ testBackingParse(const void *args) + return -1; + } + +- if (virDomainDiskSourceFormat(&buf, src, "source", 0, false, 0, true, NULL) < 0 || ++ if (virDomainDiskSourceFormat(&buf, src, "source", 0, false, xmlformatflags, true, NULL) < 0 || + !(xml = virBufferContentAndReset(&buf))) { + fprintf(stderr, "failed to format disk source xml\n"); + return -1; +-- +2.23.0 + -- Gitee From 6498ba0b23f9ba5f75f3ba56c1d61015b3638792 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Wed, 5 Aug 2020 12:54:43 +0800 Subject: [PATCH 06/44] libvirt: support aarch64 vtpm with parameter tpm-tis-device Signed-off-by: jiangfangjie --- ...upport-aarch64-vtpm-with-parameter-tpm-tis-.patch | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/libvirt-support-aarch64-vtpm-with-parameter-tpm-tis-.patch b/libvirt-support-aarch64-vtpm-with-parameter-tpm-tis-.patch index 34488d6..14e08d6 100644 --- a/libvirt-support-aarch64-vtpm-with-parameter-tpm-tis-.patch +++ b/libvirt-support-aarch64-vtpm-with-parameter-tpm-tis-.patch @@ -1,4 +1,4 @@ -From 959bbbafc3ba59e2aa00b83c88fa84a32d500def Mon Sep 17 00:00:00 2001 +From 51371f5f174cfeaeb28478aed9c85251804fe015 Mon Sep 17 00:00:00 2001 From: jiangfangjie Date: Wed, 5 Aug 2020 12:54:43 +0800 Subject: [PATCH] libvirt: support aarch64 vtpm with parameter tpm-tis-device @@ -13,7 +13,7 @@ Signed-off-by: jiangfangjie 5 files changed, 16 insertions(+) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c -index cf93a59..6192c08 100644 +index cf93a591f4..6192c08545 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -1140,6 +1140,7 @@ VIR_ENUM_IMPL(virDomainTPMModel, @@ -25,7 +25,7 @@ index cf93a59..6192c08 100644 VIR_ENUM_IMPL(virDomainTPMBackend, diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h -index 33875d9..a40773a 100644 +index 33875d942f..a40773a0f4 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -1274,6 +1274,7 @@ typedef enum { @@ -37,7 +37,7 @@ index 33875d9..a40773a 100644 VIR_DOMAIN_TPM_MODEL_LAST } virDomainTPMModel; diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c -index 73a8856..18bf37b 100644 +index 73a8856f34..18bf37b569 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -568,6 +568,9 @@ VIR_ENUM_IMPL(virQEMUCaps, @@ -70,7 +70,7 @@ index 73a8856..18bf37b 100644 static int diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h -index 51ec1a5..8e16fc0 100644 +index 51ec1a5165..8e16fc0e78 100644 --- a/src/qemu/qemu_capabilities.h +++ b/src/qemu/qemu_capabilities.h @@ -549,6 +549,9 @@ typedef enum { /* virQEMUCapsFlags grouping marker for syntax-check */ @@ -84,7 +84,7 @@ index 51ec1a5..8e16fc0 100644 QEMU_CAPS_LAST /* this must always be the last item */ } virQEMUCapsFlags; diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c -index dd48b6f..b1a4647 100644 +index dd48b6fff3..b1a46478ed 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -8118,6 +8118,9 @@ qemuDomainDeviceDefValidateTPM(virDomainTPMDef *tpm, -- Gitee From 30f861609ae316ef32132429464cdc2bc81e2826 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Mon, 4 May 2020 17:41:46 +0100 Subject: [PATCH 07/44] remote: fix driver name check for libxl driver MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The virConnectGetType() returns "Xen" for libxl, not "LIBXL". This prevents users opening a connection to the libxl driver when using the modular daemons. cherry-pick from commit: d677de9d567e3e87be295b91723457b461345caa Reviewed-by: Jim Fehlig Signed-off-by: Daniel P. Berrangé Signed-off-by: Jin Yan --- ...x-driver-name-check-for-libxl-driver.patch | 38 +++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 remote-fix-driver-name-check-for-libxl-driver.patch diff --git a/remote-fix-driver-name-check-for-libxl-driver.patch b/remote-fix-driver-name-check-for-libxl-driver.patch new file mode 100644 index 0000000..1c1bbc3 --- /dev/null +++ b/remote-fix-driver-name-check-for-libxl-driver.patch @@ -0,0 +1,38 @@ +From 5789c5420911bbe2e8decdeb863dec223e4e9e43 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= +Date: Mon, 4 May 2020 17:41:46 +0100 +Subject: [PATCH] remote: fix driver name check for libxl driver +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +The virConnectGetType() returns "Xen" for libxl, not "LIBXL". + +This prevents users opening a connection to the libxl driver when using +the modular daemons. + +cherry-pick from commit: d677de9d567e3e87be295b91723457b461345caa + +Reviewed-by: Jim Fehlig +Signed-off-by: Daniel P. Berrangé +Signed-off-by: Jin Yan +--- + src/remote/remote_daemon_dispatch.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/remote/remote_daemon_dispatch.c b/src/remote/remote_daemon_dispatch.c +index c5506c2e11..d2652e3231 100644 +--- a/src/remote/remote_daemon_dispatch.c ++++ b/src/remote/remote_daemon_dispatch.c +@@ -2111,7 +2111,7 @@ remoteDispatchConnectOpen(virNetServerPtr server G_GNUC_UNUSED, + + VIR_DEBUG("Primary driver type is '%s'", type); + if (STREQ(type, "QEMU") || +- STREQ(type, "LIBXL") || ++ STREQ(type, "Xen") || + STREQ(type, "LXC") || + STREQ(type, "VBOX") || + STREQ(type, "bhyve") || +-- +2.23.0 + -- Gitee From 0bd2100998d57786f56018db6acaa341a3e45428 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Fri, 1 May 2020 00:05:50 -0400 Subject: [PATCH 08/44] systemd: start libvirtd after firewalld/iptables services When a system has enabled the iptables/ip6tables services rather than firewalld, there is no explicit ordering of the start of those services vs. libvirtd. This creates a problem when libvirtd.service is started before ip[6]tables, as the latter, when it finally is started, will remove all of the iptables rules that had previously been added by libvirt, including the custom chains where libvirt's rules are kept. This results in an error message similar to the following when a user subsequently tries to start a new libvirt network: "Error while activating network: Call to virNetworkCreate failed: internal error: Failed to apply firewall rules /usr/sbin/ip6tables -w --table filter --insert LIBVIRT_FWO \ --in-interface virbr2 --jump REJECT: ip6tables: No chain/target/match by that name." (Prior to logging this error, it also would have caused failure to forward (or block) traffic in some cases, e.g. for guests on a NATed network, since libvirt's rules to forward/block had all been deleted and libvirt didn't know about it, so it couldn't fix the problem) When this happens, the problem can be remedied by simply restarting libvirtd.service (which has the side-effect of reloading all libvirt-generated firewall rules) Instead, we can just explicitly stating in the libvirtd.service file that libvirtd.service should start after ip6tables.service and ip6tables.service, eliminating the race condition that leads to the error. There is also nothing (that I can see) in the systemd .service files to guarantee that firewalld.service will be started (if enabled) prior to libvirtd.service. The same error scenario given above would occur if libvirtd.service started before firewalld.service. Even before that, though libvirtd would have detected that firewalld.service was disabled, and then turn off all firewalld support. So, for example, firewalld's libvirt zone wouldn't be used, and most likely traffic from guests would therefore be blocked (all with no external indication of the source of the problem other than a debug-level log when libvirtd was started saying that firewalld wasn't in use); also libvirtd wouldn't notice when firewalld reloaded its rules (which also simultaneously deletes all of libvirt's rules). I'm not aware of any reports that have been traced back to libvirtd.service starting before firewalld.service, but have seen that error reported multiple times, and also don't see an existing dependency that would guarantee firewalld.service starts before libvirtd.service, so it's possible it's been happening and we just haven't gotten to the bottom of it. This patch adds an After= line to the libvirtd.service file for each of iptables.service, ip6tables.service, and firewalld.servicee, which should guarantee that libvirtd.service isn't started until systemd has started whichever of the others is enabled. This race was diagnosed, and patch proposed, by Jason Montleon in https://bugzilla.redhat.com/1723698 . At the time (April 2019) danpb agreed with him that this change to libvirtd.service was a reasonable thing to do, but I guess everyone thought someone else was going to post a patch, so in the end nobody did. cherry-pick from commit: 0756415f147dda15a417bd79eef9a62027d176e6 Signed-off-by: Laine Stump Reviewed-by: Michal Privoznik Signed-off-by: Jin Yan --- ...bvirtd-after-firewalld-iptables-serv.patch | 106 ++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 systemd-start-libvirtd-after-firewalld-iptables-serv.patch diff --git a/systemd-start-libvirtd-after-firewalld-iptables-serv.patch b/systemd-start-libvirtd-after-firewalld-iptables-serv.patch new file mode 100644 index 0000000..f577795 --- /dev/null +++ b/systemd-start-libvirtd-after-firewalld-iptables-serv.patch @@ -0,0 +1,106 @@ +From 5bcf0f74aa9b69ec75d02772dc5c33722cabc4f4 Mon Sep 17 00:00:00 2001 +From: Laine Stump +Date: Fri, 1 May 2020 00:05:50 -0400 +Subject: [PATCH] systemd: start libvirtd after firewalld/iptables services + +When a system has enabled the iptables/ip6tables services rather than +firewalld, there is no explicit ordering of the start of those +services vs. libvirtd. This creates a problem when libvirtd.service is +started before ip[6]tables, as the latter, when it finally is started, +will remove all of the iptables rules that had previously been added +by libvirt, including the custom chains where libvirt's rules are +kept. This results in an error message similar to the following when a +user subsequently tries to start a new libvirt network: + + "Error while activating network: Call to virNetworkCreate failed: + internal error: Failed to apply firewall rules + /usr/sbin/ip6tables -w --table filter --insert LIBVIRT_FWO \ + --in-interface virbr2 --jump REJECT: + ip6tables: No chain/target/match by that name." + +(Prior to logging this error, it also would have caused failure to +forward (or block) traffic in some cases, e.g. for guests on a NATed +network, since libvirt's rules to forward/block had all been deleted +and libvirt didn't know about it, so it couldn't fix the problem) + +When this happens, the problem can be remedied by simply restarting +libvirtd.service (which has the side-effect of reloading all +libvirt-generated firewall rules) + +Instead, we can just explicitly stating in the libvirtd.service file +that libvirtd.service should start after ip6tables.service and +ip6tables.service, eliminating the race condition that leads to the +error. + +There is also nothing (that I can see) in the systemd .service files +to guarantee that firewalld.service will be started (if enabled) prior +to libvirtd.service. The same error scenario given above would occur +if libvirtd.service started before firewalld.service. Even before +that, though libvirtd would have detected that firewalld.service was +disabled, and then turn off all firewalld support. So, for example, +firewalld's libvirt zone wouldn't be used, and most likely traffic +from guests would therefore be blocked (all with no external +indication of the source of the problem other than a debug-level log +when libvirtd was started saying that firewalld wasn't in use); also +libvirtd wouldn't notice when firewalld reloaded its rules (which also +simultaneously deletes all of libvirt's rules). + +I'm not aware of any reports that have been traced back to +libvirtd.service starting before firewalld.service, but have seen that +error reported multiple times, and also don't see an existing +dependency that would guarantee firewalld.service starts before +libvirtd.service, so it's possible it's been happening and we just +haven't gotten to the bottom of it. + +This patch adds an After= line to the libvirtd.service file for each +of iptables.service, ip6tables.service, and firewalld.servicee, which +should guarantee that libvirtd.service isn't started until systemd has +started whichever of the others is enabled. + +This race was diagnosed, and patch proposed, by Jason Montleon in +https://bugzilla.redhat.com/1723698 . At the time (April 2019) danpb +agreed with him that this change to libvirtd.service was a reasonable +thing to do, but I guess everyone thought someone else was going to +post a patch, so in the end nobody did. + +cherry-pick from commit: 0756415f147dda15a417bd79eef9a62027d176e6 + +Signed-off-by: Laine Stump +Reviewed-by: Michal Privoznik +Signed-off-by: Jin Yan +--- + src/network/virtnetworkd.service.in | 3 +++ + src/remote/libvirtd.service.in | 3 +++ + 2 files changed, 6 insertions(+) + +diff --git a/src/network/virtnetworkd.service.in b/src/network/virtnetworkd.service.in +index 656e8b4f84..56182e1693 100644 +--- a/src/network/virtnetworkd.service.in ++++ b/src/network/virtnetworkd.service.in +@@ -5,6 +5,9 @@ Requires=virtnetworkd.socket + Requires=virtnetworkd-ro.socket + Requires=virtnetworkd-admin.socket + After=network.target ++After=firewalld.service ++After=iptables.service ++After=ip6tables.service + After=dbus.service + After=apparmor.service + After=local-fs.target +diff --git a/src/remote/libvirtd.service.in b/src/remote/libvirtd.service.in +index 90b2cad5b0..cc0d4e3693 100644 +--- a/src/remote/libvirtd.service.in ++++ b/src/remote/libvirtd.service.in +@@ -11,6 +11,9 @@ Wants=libvirtd-admin.socket + Wants=systemd-machined.service + Before=libvirt-guests.service + After=network.target ++After=firewalld.service ++After=iptables.service ++After=ip6tables.service + After=dbus.service + After=iscsid.service + After=apparmor.service +-- +2.23.0 + -- Gitee From b8c0701f29e8fbbee95210de4176435591d0a383 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Tue, 5 May 2020 13:45:44 +0200 Subject: [PATCH 09/44] qemuDomainCleanupRun: Actually run cleanup callbacks in reverse order MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We have a framework to register cleanup callbacks that are run when a domain is shut down. The idea is to run callbacks in reverse order than they were registered. However, looking at the code this is not the case. Fortunately, this framework is used to register a single callback and a single callback only - qemuMigrationDstPrepareCleanup() - therefore there was no problem just yet. cherry-pick from commit: 06fc99b6ceb846b07e1cae3d82916ef50ca5f60e Signed-off-by: Michal Privoznik Reviewed-by: Ján Tomko Signed-off-by: Jin Yan --- ...pRun-Actually-run-cleanup-callbacks-.patch | 54 +++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 qemuDomainCleanupRun-Actually-run-cleanup-callbacks-.patch diff --git a/qemuDomainCleanupRun-Actually-run-cleanup-callbacks-.patch b/qemuDomainCleanupRun-Actually-run-cleanup-callbacks-.patch new file mode 100644 index 0000000..be9af7d --- /dev/null +++ b/qemuDomainCleanupRun-Actually-run-cleanup-callbacks-.patch @@ -0,0 +1,54 @@ +From 06115c4609b391733fc5c36a39604c8a4b54fc8e Mon Sep 17 00:00:00 2001 +From: Michal Privoznik +Date: Tue, 5 May 2020 13:45:44 +0200 +Subject: [PATCH] qemuDomainCleanupRun: Actually run cleanup callbacks in + reverse order +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +We have a framework to register cleanup callbacks that are run +when a domain is shut down. The idea is to run callbacks in +reverse order than they were registered. However, looking at the +code this is not the case. Fortunately, this framework is used to +register a single callback and a single callback only - +qemuMigrationDstPrepareCleanup() - therefore there was no problem +just yet. + +cherry-pick from commit: 06fc99b6ceb846b07e1cae3d82916ef50ca5f60e + +Signed-off-by: Michal Privoznik +Reviewed-by: Ján Tomko +Signed-off-by: Jin Yan +--- + src/qemu/qemu_domain.c | 8 ++------ + 1 file changed, 2 insertions(+), 6 deletions(-) + +diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c +index b1a46478ed..36bef6717b 100644 +--- a/src/qemu/qemu_domain.c ++++ b/src/qemu/qemu_domain.c +@@ -11561,18 +11561,14 @@ qemuDomainCleanupRun(virQEMUDriverPtr driver, + virDomainObjPtr vm) + { + qemuDomainObjPrivatePtr priv = vm->privateData; +- size_t i; + + VIR_DEBUG("driver=%p, vm=%s", driver, vm->def->name); + + /* run cleanup callbacks in reverse order */ +- for (i = 0; i < priv->ncleanupCallbacks; i++) { +- if (priv->cleanupCallbacks[priv->ncleanupCallbacks - (i + 1)]) +- priv->cleanupCallbacks[i](driver, vm); +- } ++ while (priv->ncleanupCallbacks) ++ priv->cleanupCallbacks[--priv->ncleanupCallbacks](driver, vm); + + VIR_FREE(priv->cleanupCallbacks); +- priv->ncleanupCallbacks = 0; + priv->ncleanupCallbacks_max = 0; + } + +-- +2.23.0 + -- Gitee From 76f5efa329d5d1d1bfee74d79e07bc1c57758e47 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Fri, 24 Apr 2020 13:17:51 +0200 Subject: [PATCH 10/44] virDevMapperGetTargetsImpl: quit early if device is not a devmapper target MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit As suggested in the linked bug, libvirt should firstly check whether the major number of the device is device mapper major. Because if it isn't subsequent DM_DEVICE_DEPS task may not only fail, but also yield different results. In the bugzilla this is demonstrated by creating a devmapper target named 'loop0' and then creating loop target /dev/loop0. When the latter is then passed to a domain, our virDevMapperGetTargetsImpl() function blindly asks devmapper to provide target dependencies for /dev/loop0 and because of the way devmapper APIs work, it will 'sanitize' the input by using the last component only which is 'loop0' and thus return different results than expected. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1823976 cherry-pick from commit: 01626c668ecfbe465d18799ac4628e6127ea1d47 Signed-off-by: Michal Privoznik Reviewed-by: Ján Tomko Signed-off-by: Jin Yan --- ...argetsImpl-quit-early-if-device-is-n.patch | 63 +++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 virDevMapperGetTargetsImpl-quit-early-if-device-is-n.patch diff --git a/virDevMapperGetTargetsImpl-quit-early-if-device-is-n.patch b/virDevMapperGetTargetsImpl-quit-early-if-device-is-n.patch new file mode 100644 index 0000000..5e555da --- /dev/null +++ b/virDevMapperGetTargetsImpl-quit-early-if-device-is-n.patch @@ -0,0 +1,63 @@ +From 0ed174e5320f8ea42832725260675af06ee95697 Mon Sep 17 00:00:00 2001 +From: Michal Privoznik +Date: Fri, 24 Apr 2020 13:17:51 +0200 +Subject: [PATCH] virDevMapperGetTargetsImpl: quit early if device is not a + devmapper target +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +As suggested in the linked bug, libvirt should firstly check +whether the major number of the device is device mapper major. +Because if it isn't subsequent DM_DEVICE_DEPS task may not only +fail, but also yield different results. In the bugzilla this is +demonstrated by creating a devmapper target named 'loop0' and +then creating loop target /dev/loop0. When the latter is then +passed to a domain, our virDevMapperGetTargetsImpl() function +blindly asks devmapper to provide target dependencies for +/dev/loop0 and because of the way devmapper APIs work, it will +'sanitize' the input by using the last component only which is +'loop0' and thus return different results than expected. + +Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1823976 + +cherry-pick from commit: 01626c668ecfbe465d18799ac4628e6127ea1d47 + +Signed-off-by: Michal Privoznik +Reviewed-by: Ján Tomko +Signed-off-by: Jin Yan +--- + src/util/virdevmapper.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +diff --git a/src/util/virdevmapper.c b/src/util/virdevmapper.c +index feb5982315..79dbc3d02a 100644 +--- a/src/util/virdevmapper.c ++++ b/src/util/virdevmapper.c +@@ -64,6 +64,7 @@ virDevMapperGetTargetsImpl(const char *path, + char ***devPaths_ret, + unsigned int ttl) + { ++ struct stat sb; + struct dm_task *dmt = NULL; + struct dm_deps *deps; + struct dm_info info; +@@ -82,6 +83,15 @@ virDevMapperGetTargetsImpl(const char *path, + return ret; + } + ++ if (stat(path, &sb) < 0) { ++ if (errno == ENOENT) ++ return 0; ++ return -1; ++ } ++ ++ if (!dm_is_dm_major(major(sb.st_dev))) ++ return 0; ++ + if (!(dmt = dm_task_create(DM_DEVICE_DEPS))) { + if (errno == ENOENT || errno == ENODEV) { + /* It's okay. Kernel is probably built without +-- +2.23.0 + -- Gitee From 9cc0918bd7ce601b7c3d1502eef64836411cd4f4 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Tue, 12 May 2020 12:59:07 +0200 Subject: [PATCH 11/44] qemu: only stop external devices after the domain MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A failure in qemuProcessLaunch would lead to qemuExtDevicesStop being called twice - once in the cleanup section and then again in qemuProcessStop. However, the first one is called while the QEMU process is still running, which is too soon for the swtpm process, because the swtmp_ioctl command can lock up: https://bugzilla.redhat.com/show_bug.cgi?id=1822523 Remove the first call and only leave the one in qemuProcessStop, which is called after the QEMU process is killed. cherry-pick from commit: 006782a8bc5a27125211946fcb12a40f7d4ed12a Signed-off-by: Ján Tomko Reviewed-by: Daniel Henrique Barboza Reviewed-by: Erik Skultety Signed-off-by: Jin Yan --- ...op-external-devices-after-the-domain.patch | 47 +++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 qemu-only-stop-external-devices-after-the-domain.patch diff --git a/qemu-only-stop-external-devices-after-the-domain.patch b/qemu-only-stop-external-devices-after-the-domain.patch new file mode 100644 index 0000000..f683ccf --- /dev/null +++ b/qemu-only-stop-external-devices-after-the-domain.patch @@ -0,0 +1,47 @@ +From 3fa049e018401079a60b060c4181539ed7ec7b28 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?J=C3=A1n=20Tomko?= +Date: Tue, 12 May 2020 12:59:07 +0200 +Subject: [PATCH] qemu: only stop external devices after the domain +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +A failure in qemuProcessLaunch would lead to qemuExtDevicesStop +being called twice - once in the cleanup section and then again +in qemuProcessStop. + +However, the first one is called while the QEMU process is +still running, which is too soon for the swtpm process, because +the swtmp_ioctl command can lock up: + +https://bugzilla.redhat.com/show_bug.cgi?id=1822523 + +Remove the first call and only leave the one in qemuProcessStop, +which is called after the QEMU process is killed. + +cherry-pick from commit: 006782a8bc5a27125211946fcb12a40f7d4ed12a + +Signed-off-by: Ján Tomko +Reviewed-by: Daniel Henrique Barboza +Reviewed-by: Erik Skultety +Signed-off-by: Jin Yan +--- + src/qemu/qemu_process.c | 2 -- + 1 file changed, 2 deletions(-) + +diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c +index 6b9f6fb860..6fbe0c1800 100644 +--- a/src/qemu/qemu_process.c ++++ b/src/qemu/qemu_process.c +@@ -6998,8 +6998,6 @@ qemuProcessLaunch(virConnectPtr conn, + ret = 0; + + cleanup: +- if (ret < 0) +- qemuExtDevicesStop(driver, vm); + qemuDomainSecretDestroy(vm); + return ret; + } +-- +2.23.0 + -- Gitee From d52037462c60f6c64083205ceb8ad90da5f9413d Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Thu, 14 May 2020 10:47:42 +0200 Subject: [PATCH 12/44] qemuDomainStorageSourcePrivateDispose: Free httpcookie ==156803== 58 (40 direct, 18 indirect) bytes in 1 blocks are definitely lost in loss record 306 of 463 ==156803== at 0x4839EC6: calloc (vg_replace_malloc.c:762) ==156803== by 0x5791AC0: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6400.1) ==156803== by 0x48F60DC: virAlloc (viralloc.c:48) ==156803== by 0x18DD74: qemuStorageSourcePrivateDataAssignSecinfo (qemu_domain.c:2384) ==156803== by 0x18DFD5: qemuStorageSourcePrivateDataParse (qemu_domain.c:2433) ==156803== by 0x49EC884: virDomainStorageSourceParse (domain_conf.c:9857) ==156803== by 0x49ECBA3: virDomainDiskBackingStoreParse (domain_conf.c:9909) ==156803== by 0x49F129D: virDomainDiskDefParseXML (domain_conf.c:10785) ==156803== by 0x4A1804E: virDomainDefParseXML (domain_conf.c:21543) ==156803== by 0x4A1B60C: virDomainObjParseXML (domain_conf.c:22254) ==156803== by 0x4A1BFE9: virDomainObjParseNode (domain_conf.c:22429) ==156803== by 0x4A1C0B4: virDomainObjParseFile (domain_conf.c:22443 cherry-pick from commit: 42a415d5a548d828c4b6bd42ad59dfc44b113fa9 Signed-off-by: Michal Privoznik Reviewed-by: Peter Krempa Signed-off-by: Jin Yan --- ...eSourcePrivateDispose-Free-httpcooki.patch | 43 +++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 qemuDomainStorageSourcePrivateDispose-Free-httpcooki.patch diff --git a/qemuDomainStorageSourcePrivateDispose-Free-httpcooki.patch b/qemuDomainStorageSourcePrivateDispose-Free-httpcooki.patch new file mode 100644 index 0000000..3bcbc45 --- /dev/null +++ b/qemuDomainStorageSourcePrivateDispose-Free-httpcooki.patch @@ -0,0 +1,43 @@ +From 1140e2c41007e955674dfe76186097641ed1332c Mon Sep 17 00:00:00 2001 +From: Michal Privoznik +Date: Thu, 14 May 2020 10:47:42 +0200 +Subject: [PATCH] qemuDomainStorageSourcePrivateDispose: Free httpcookie + +==156803== 58 (40 direct, 18 indirect) bytes in 1 blocks are definitely lost in loss record 306 of 463 +==156803== at 0x4839EC6: calloc (vg_replace_malloc.c:762) +==156803== by 0x5791AC0: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6400.1) +==156803== by 0x48F60DC: virAlloc (viralloc.c:48) +==156803== by 0x18DD74: qemuStorageSourcePrivateDataAssignSecinfo (qemu_domain.c:2384) +==156803== by 0x18DFD5: qemuStorageSourcePrivateDataParse (qemu_domain.c:2433) +==156803== by 0x49EC884: virDomainStorageSourceParse (domain_conf.c:9857) +==156803== by 0x49ECBA3: virDomainDiskBackingStoreParse (domain_conf.c:9909) +==156803== by 0x49F129D: virDomainDiskDefParseXML (domain_conf.c:10785) +==156803== by 0x4A1804E: virDomainDefParseXML (domain_conf.c:21543) +==156803== by 0x4A1B60C: virDomainObjParseXML (domain_conf.c:22254) +==156803== by 0x4A1BFE9: virDomainObjParseNode (domain_conf.c:22429) +==156803== by 0x4A1C0B4: virDomainObjParseFile (domain_conf.c:22443 + +cherry-pick from commit: 42a415d5a548d828c4b6bd42ad59dfc44b113fa9 + +Signed-off-by: Michal Privoznik +Reviewed-by: Peter Krempa +Signed-off-by: Jin Yan +--- + src/qemu/qemu_domain.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c +index 36bef6717b..91c1a49efa 100644 +--- a/src/qemu/qemu_domain.c ++++ b/src/qemu/qemu_domain.c +@@ -1203,6 +1203,7 @@ qemuDomainStorageSourcePrivateDispose(void *obj) + + g_clear_pointer(&priv->secinfo, qemuDomainSecretInfoFree); + g_clear_pointer(&priv->encinfo, qemuDomainSecretInfoFree); ++ g_clear_pointer(&priv->httpcookie, qemuDomainSecretInfoFree); + } + + +-- +2.23.0 + -- Gitee From 0d99e2c2aa07c8b50a179dbc9cbe035fd3d737c3 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Mon, 18 May 2020 10:07:30 +0200 Subject: [PATCH 13/44] Don't require secdrivers to implement .domainMoveImageMetadata The AppArmor secdriver does not use labels to grant access to resources. Therefore, it doesn't use XATTRs and hence it lacks implementation of .domainMoveImageMetadata callback. This leads to a harmless but needless error message appearing in the logs: virSecurityManagerMoveImageMetadata:476 : this function is not supported by the connection driver: virSecurityManagerMoveImageMetadata Closes: https://gitlab.com/libvirt/libvirt/-/issues/25 cherry-pick from commit: cc8c297e473afd55e5d8e35e18345d8df176059d Signed-off-by: Michal Privoznik Reviewed-by: Erik Skultety Signed-off-by: Jin Yan --- ...cdrivers-to-implement-.domainMoveIma.patch | 42 +++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 Don-t-require-secdrivers-to-implement-.domainMoveIma.patch diff --git a/Don-t-require-secdrivers-to-implement-.domainMoveIma.patch b/Don-t-require-secdrivers-to-implement-.domainMoveIma.patch new file mode 100644 index 0000000..8cb380e --- /dev/null +++ b/Don-t-require-secdrivers-to-implement-.domainMoveIma.patch @@ -0,0 +1,42 @@ +From bfde8ecd49d09f4690c5d309d95c0371fcb82636 Mon Sep 17 00:00:00 2001 +From: Michal Privoznik +Date: Mon, 18 May 2020 10:07:30 +0200 +Subject: [PATCH] Don't require secdrivers to implement + .domainMoveImageMetadata + +The AppArmor secdriver does not use labels to grant access to +resources. Therefore, it doesn't use XATTRs and hence it lacks +implementation of .domainMoveImageMetadata callback. This leads +to a harmless but needless error message appearing in the logs: + + virSecurityManagerMoveImageMetadata:476 : this function is not + supported by the connection driver: virSecurityManagerMoveImageMetadata + +Closes: https://gitlab.com/libvirt/libvirt/-/issues/25 + +cherry-pick from commit: cc8c297e473afd55e5d8e35e18345d8df176059d + +Signed-off-by: Michal Privoznik +Reviewed-by: Erik Skultety +Signed-off-by: Jin Yan +--- + src/security/security_manager.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/src/security/security_manager.c b/src/security/security_manager.c +index fe032746ff..1445291410 100644 +--- a/src/security/security_manager.c ++++ b/src/security/security_manager.c +@@ -473,8 +473,7 @@ virSecurityManagerMoveImageMetadata(virSecurityManagerPtr mgr, + return ret; + } + +- virReportUnsupportedError(); +- return -1; ++ return 0; + } + + +-- +2.23.0 + -- Gitee From d455284349a4e685a5cd5d1119e60dd526e27ca3 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Mon, 18 May 2020 15:07:46 +0200 Subject: [PATCH 14/44] qemuProcessStop: Use XATTRs to restore seclabels on disks a domain is mirroring into In v5.10.0-rc1~42 (which was later fixed in v6.0.0-rc1~487) I am removing XATTRs for a file that QEMU is mirroring a disk into but it is killed meanwhile. Well, we can call qemuSecurityRestoreImageLabel() which will not only remove XATTRs but also use them to restore the original owner of the file. This would be done by blockjob code when the job finishes, but in this case the job won't finish - QEMU is killed meanwhile cherry-pick from commit: 0230e3838402624756d6cd913b7d92639fafc7d0 Signed-off-by: Michal Privoznik Reviewed-by: Peter Krempa Signed-off-by: Jin Yan --- ...Use-XATTRs-to-restore-seclabels-on-d.patch | 44 +++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 qemuProcessStop-Use-XATTRs-to-restore-seclabels-on-d.patch diff --git a/qemuProcessStop-Use-XATTRs-to-restore-seclabels-on-d.patch b/qemuProcessStop-Use-XATTRs-to-restore-seclabels-on-d.patch new file mode 100644 index 0000000..fc9d468 --- /dev/null +++ b/qemuProcessStop-Use-XATTRs-to-restore-seclabels-on-d.patch @@ -0,0 +1,44 @@ +From 37057f03763c867f1bc0270e2feebd53d43bea02 Mon Sep 17 00:00:00 2001 +From: Michal Privoznik +Date: Mon, 18 May 2020 15:07:46 +0200 +Subject: [PATCH] qemuProcessStop: Use XATTRs to restore seclabels on disks a + domain is mirroring into + +In v5.10.0-rc1~42 (which was later fixed in v6.0.0-rc1~487) I am +removing XATTRs for a file that QEMU is mirroring a disk into but +it is killed meanwhile. Well, we can call +qemuSecurityRestoreImageLabel() which will not only remove XATTRs +but also use them to restore the original owner of the file. + +This would be done by blockjob code when the job finishes, but in +this case the job won't finish - QEMU is killed meanwhile + +cherry-pick from commit: 0230e3838402624756d6cd913b7d92639fafc7d0 + +Signed-off-by: Michal Privoznik +Reviewed-by: Peter Krempa +Signed-off-by: Jin Yan +--- + src/qemu/qemu_process.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c +index 6fbe0c1800..9285acecce 100644 +--- a/src/qemu/qemu_process.c ++++ b/src/qemu/qemu_process.c +@@ -7603,8 +7603,10 @@ void qemuProcessStop(virQEMUDriverPtr driver, + for (i = 0; i < def->ndisks; i++) { + virDomainDiskDefPtr disk = def->disks[i]; + +- if (disk->mirror) +- qemuBlockRemoveImageMetadata(driver, vm, disk->dst, disk->mirror); ++ if (disk->mirror) { ++ if (qemuSecurityRestoreImageLabel(driver, vm, disk->mirror, false) < 0) ++ VIR_WARN("Unable to restore security label on %s", disk->dst); ++ } + + qemuBlockRemoveImageMetadata(driver, vm, disk->dst, disk->src); + } +-- +2.23.0 + -- Gitee From c0fb801b8c28e346b2f767ff8028e9bb33157cfc Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Mon, 18 May 2020 15:11:49 +0200 Subject: [PATCH 15/44] qemuProcessStop: Reattach NVMe disks a domain is mirroring into If the mirror destination is not a file but a NVMe disk, then call qemuHostdevReAttachOneNVMeDisk() to reattach the NVMe back to the host. This would be done by blockjob code when the job finishes, but in this case the job won't finish - QEMU is killed meanwhile. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1825785 cherry-pick from commit: 8fd2749b2df99f3ac27215e9e4ab8be191c39460 Signed-off-by: Michal Privoznik Reviewed-by: Peter Krempa Signed-off-by: Jin Yan --- ...Reattach-NVMe-disks-a-domain-is-mirr.patch | 41 +++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 qemuProcessStop-Reattach-NVMe-disks-a-domain-is-mirr.patch diff --git a/qemuProcessStop-Reattach-NVMe-disks-a-domain-is-mirr.patch b/qemuProcessStop-Reattach-NVMe-disks-a-domain-is-mirr.patch new file mode 100644 index 0000000..225404e --- /dev/null +++ b/qemuProcessStop-Reattach-NVMe-disks-a-domain-is-mirr.patch @@ -0,0 +1,41 @@ +From 56650365ad626230d3b3fd36aab24067cd657dd8 Mon Sep 17 00:00:00 2001 +From: Michal Privoznik +Date: Mon, 18 May 2020 15:11:49 +0200 +Subject: [PATCH] qemuProcessStop: Reattach NVMe disks a domain is mirroring + into + +If the mirror destination is not a file but a NVMe disk, then +call qemuHostdevReAttachOneNVMeDisk() to reattach the NVMe back +to the host. + +This would be done by blockjob code when the job finishes, but in +this case the job won't finish - QEMU is killed meanwhile. + +Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1825785 + +cherry-pick from commit: 8fd2749b2df99f3ac27215e9e4ab8be191c39460 + +Signed-off-by: Michal Privoznik +Reviewed-by: Peter Krempa +Signed-off-by: Jin Yan +--- + src/qemu/qemu_process.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c +index 9285acecce..280fed932a 100644 +--- a/src/qemu/qemu_process.c ++++ b/src/qemu/qemu_process.c +@@ -7606,6 +7606,9 @@ void qemuProcessStop(virQEMUDriverPtr driver, + if (disk->mirror) { + if (qemuSecurityRestoreImageLabel(driver, vm, disk->mirror, false) < 0) + VIR_WARN("Unable to restore security label on %s", disk->dst); ++ ++ if (virStorageSourceChainHasNVMe(disk->mirror)) ++ qemuHostdevReAttachOneNVMeDisk(driver, vm->def->name, disk->mirror); + } + + qemuBlockRemoveImageMetadata(driver, vm, disk->dst, disk->src); +-- +2.23.0 + -- Gitee From ff29f8f624cfd5f15e522f3f5e013ae290048cfc Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Tue, 26 May 2020 09:33:38 +0200 Subject: [PATCH 16/44] security: don't fail if built without attr support If built without attr support removing any image will trigger qemuBlockRemoveImageMetadata (the one that emits the warning) -> qemuSecurityMoveImageMetadata -> virSecurityManagerMoveImageMetadata -> virSecurityDACMoveImageMetadata -> virSecurityDACMoveImageMetadataHelper -> virProcessRunInFork (spawns subprocess) -> virSecurityMoveRememberedLabel In there due to !HAVE_LIBATTR virFileGetXAttrQuiet will return ENOSYS and from there the chain will error out. That is wrong and looks like: libvirtd[6320]: internal error: child reported (status=125): libvirtd[6320]: Unable to remove disk metadata on vm testguest from /var/lib/uvtool/libvirt/images/testguest.qcow (disk target vda) This change makes virSecurityDACMoveImageMetadataHelper and virSecuritySELinuxMoveImageMetadataHelper accept that error code gracefully and in that sense it is an extension of: 5214b2f1a3f "security: Don't skip label restore on file systems lacking XATTRs" which does the same for other call chains into the virFile*XAttr functions. cherry-pick from commit: 55029d93150e33d70b02b6de2b899c05054c5d3a Signed-off-by: Christian Ehrhardt Reviewed-by: Michal Privoznik Signed-off-by: Jin Yan --- ...t-fail-if-built-without-attr-support.patch | 75 +++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 security-don-t-fail-if-built-without-attr-support.patch diff --git a/security-don-t-fail-if-built-without-attr-support.patch b/security-don-t-fail-if-built-without-attr-support.patch new file mode 100644 index 0000000..59de0a1 --- /dev/null +++ b/security-don-t-fail-if-built-without-attr-support.patch @@ -0,0 +1,75 @@ +From 03f4b3ff60292a3a58e38e8da8085d47d842d7f7 Mon Sep 17 00:00:00 2001 +From: Christian Ehrhardt +Date: Tue, 26 May 2020 09:33:38 +0200 +Subject: [PATCH] security: don't fail if built without attr support + +If built without attr support removing any image will trigger + qemuBlockRemoveImageMetadata (the one that emits the warning) + -> qemuSecurityMoveImageMetadata + -> virSecurityManagerMoveImageMetadata + -> virSecurityDACMoveImageMetadata + -> virSecurityDACMoveImageMetadataHelper + -> virProcessRunInFork (spawns subprocess) + -> virSecurityMoveRememberedLabel + +In there due to !HAVE_LIBATTR virFileGetXAttrQuiet will return +ENOSYS and from there the chain will error out. + +That is wrong and looks like: + libvirtd[6320]: internal error: child reported (status=125): + libvirtd[6320]: Unable to remove disk metadata on vm testguest from + /var/lib/uvtool/libvirt/images/testguest.qcow (disk target vda) + +This change makes virSecurityDACMoveImageMetadataHelper and +virSecuritySELinuxMoveImageMetadataHelper accept that +error code gracefully and in that sense it is an extension of: +5214b2f1a3f "security: Don't skip label restore on file systems lacking XATTRs" +which does the same for other call chains into the virFile*XAttr functions. + +cherry-pick from commit: 55029d93150e33d70b02b6de2b899c05054c5d3a + +Signed-off-by: Christian Ehrhardt +Reviewed-by: Michal Privoznik +Signed-off-by: Jin Yan +--- + src/security/security_dac.c | 6 ++++++ + src/security/security_selinux.c | 6 ++++++ + 2 files changed, 12 insertions(+) + +diff --git a/src/security/security_dac.c b/src/security/security_dac.c +index 11fff63bc7..51cabf1961 100644 +--- a/src/security/security_dac.c ++++ b/src/security/security_dac.c +@@ -1132,6 +1132,12 @@ virSecurityDACMoveImageMetadataHelper(pid_t pid G_GNUC_UNUSED, + + ret = virSecurityMoveRememberedLabel(SECURITY_DAC_NAME, data->src, data->dst); + virSecurityManagerMetadataUnlock(data->mgr, &state); ++ ++ if (ret == -2) { ++ /* Libvirt built without XATTRS */ ++ ret = 0; ++ } ++ + return ret; + } + +diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c +index 72d1658e05..78ea618e63 100644 +--- a/src/security/security_selinux.c ++++ b/src/security/security_selinux.c +@@ -1990,6 +1990,12 @@ virSecuritySELinuxMoveImageMetadataHelper(pid_t pid G_GNUC_UNUSED, + + ret = virSecurityMoveRememberedLabel(SECURITY_SELINUX_NAME, data->src, data->dst); + virSecurityManagerMetadataUnlock(data->mgr, &state); ++ ++ if (ret == -2) { ++ /* Libvirt built without XATTRS */ ++ ret = 0; ++ } ++ + return ret; + } + +-- +2.23.0 + -- Gitee From c692abc555209e7233390eba380c5aed7fe398cf Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Tue, 26 May 2020 16:26:25 +0200 Subject: [PATCH 17/44] qemu: Skip pre-creation of NVMe disks MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Upon migration with disks, libvirt determines if each disk exists on the destination and tries to pre-create missing ones. Well, NVMe disks can't be pre-created, but they can be checked for presence. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1823639 cherry-pick from commit: a5a297f387fee9e9aa4cbc2df6788c330fd33ad1 Signed-off-by: Michal Privoznik Reviewed-by: Ján Tomko Signed-off-by: Jin Yan --- qemu-Skip-pre-creation-of-NVMe-disks.patch | 53 ++++++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 qemu-Skip-pre-creation-of-NVMe-disks.patch diff --git a/qemu-Skip-pre-creation-of-NVMe-disks.patch b/qemu-Skip-pre-creation-of-NVMe-disks.patch new file mode 100644 index 0000000..662290a --- /dev/null +++ b/qemu-Skip-pre-creation-of-NVMe-disks.patch @@ -0,0 +1,53 @@ +From 56e3bc6478ec8d51cd25b2f5ad93ad2ea1b0719d Mon Sep 17 00:00:00 2001 +From: Michal Privoznik +Date: Tue, 26 May 2020 16:26:25 +0200 +Subject: [PATCH] qemu: Skip pre-creation of NVMe disks +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Upon migration with disks, libvirt determines if each disk exists +on the destination and tries to pre-create missing ones. Well, +NVMe disks can't be pre-created, but they can be checked for +presence. + +Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1823639 + +cherry-pick from commit: a5a297f387fee9e9aa4cbc2df6788c330fd33ad1 + +Signed-off-by: Michal Privoznik +Reviewed-by: Ján Tomko +Signed-off-by: Jin Yan +--- + src/qemu/qemu_migration.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c +index 65b47ec657..3f4627bd39 100644 +--- a/src/qemu/qemu_migration.c ++++ b/src/qemu/qemu_migration.c +@@ -315,6 +315,7 @@ qemuMigrationDstPrecreateStorage(virDomainObjPtr vm, + for (i = 0; i < nbd->ndisks; i++) { + virDomainDiskDefPtr disk; + const char *diskSrcPath; ++ g_autofree char *nvmePath = NULL; + + VIR_DEBUG("Looking up disk target '%s' (capacity=%llu)", + nbd->disks[i].target, nbd->disks[i].capacity); +@@ -326,7 +327,12 @@ qemuMigrationDstPrecreateStorage(virDomainObjPtr vm, + goto cleanup; + } + +- diskSrcPath = virDomainDiskGetSource(disk); ++ if (disk->src->type == VIR_STORAGE_TYPE_NVME) { ++ virPCIDeviceAddressGetSysfsFile(&disk->src->nvme->pciAddr, &nvmePath); ++ diskSrcPath = nvmePath; ++ } else { ++ diskSrcPath = virDomainDiskGetSource(disk); ++ } + + /* Skip disks we don't want to migrate and already existing disks. */ + if (!qemuMigrationAnyCopyDisk(disk, nmigrate_disks, migrate_disks) || +-- +2.23.0 + -- Gitee From c95d15f7dd8ad78e8dbfa89017a0eacb696ee39c Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Sat, 6 Jun 2020 18:52:35 +0800 Subject: [PATCH 18/44] Fix some wrong usage of ATTRIBUTE_NONNULL() The virStateInitialize() function has ATTRIBUTE_NONNULL() referring to @root argument (incorrectly anyway) but in daemonRunStateInit() NULL is passed in anyway. Then there is virCommandAddArgPair() which also has ATTRIBUTE_NONNULL() for one of its arguments and then checks the argument for being NULL anyways. cherry-pick from commit: 2a372a5ad5fab3bf26fb9bea019d38fa04ba8b34 Signed-off-by:Bihong Yu Reviewed-by:Chuan Zheng Signed-off-by: Michal Privoznik Reviewed-by: Michal Privoznik Signed-off-by: Jin Yan --- ...ome-wrong-usage-of-ATTRIBUTE_NONNULL.patch | 56 +++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 Fix-some-wrong-usage-of-ATTRIBUTE_NONNULL.patch diff --git a/Fix-some-wrong-usage-of-ATTRIBUTE_NONNULL.patch b/Fix-some-wrong-usage-of-ATTRIBUTE_NONNULL.patch new file mode 100644 index 0000000..00872b9 --- /dev/null +++ b/Fix-some-wrong-usage-of-ATTRIBUTE_NONNULL.patch @@ -0,0 +1,56 @@ +From 116115cdd9f8b8b150356f3f64d4e57e4357ecca Mon Sep 17 00:00:00 2001 +From: Bihong Yu +Date: Sat, 6 Jun 2020 18:52:35 +0800 +Subject: [PATCH] Fix some wrong usage of ATTRIBUTE_NONNULL() + +The virStateInitialize() function has ATTRIBUTE_NONNULL() +referring to @root argument (incorrectly anyway) but in +daemonRunStateInit() NULL is passed in anyway. + +Then there is virCommandAddArgPair() which also has +ATTRIBUTE_NONNULL() for one of its arguments and then checks the +argument for being NULL anyways. + +cherry-pick from commit: 2a372a5ad5fab3bf26fb9bea019d38fa04ba8b34 + +Signed-off-by:Bihong Yu +Reviewed-by:Chuan Zheng +Signed-off-by: Michal Privoznik +Reviewed-by: Michal Privoznik +Signed-off-by: Jin Yan +--- + src/libvirt_internal.h | 3 +-- + src/util/vircommand.h | 3 +-- + 2 files changed, 2 insertions(+), 4 deletions(-) + +diff --git a/src/libvirt_internal.h b/src/libvirt_internal.h +index 00ef7aaf25..72c61274a7 100644 +--- a/src/libvirt_internal.h ++++ b/src/libvirt_internal.h +@@ -33,8 +33,7 @@ int virStateInitialize(bool privileged, + bool mandatory, + const char *root, + virStateInhibitCallback inhibit, +- void *opaque) +- ATTRIBUTE_NONNULL(2); ++ void *opaque); + int virStateCleanup(void); + int virStateReload(void); + int virStateStop(void); +diff --git a/src/util/vircommand.h b/src/util/vircommand.h +index 9086f9a90c..4e6cb0ac0d 100644 +--- a/src/util/vircommand.h ++++ b/src/util/vircommand.h +@@ -128,8 +128,7 @@ void virCommandAddArgFormat(virCommandPtr cmd, + + void virCommandAddArgPair(virCommandPtr cmd, + const char *name, +- const char *val) +- ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(3); ++ const char *val); + + void virCommandAddArgSet(virCommandPtr cmd, + const char *const*vals) ATTRIBUTE_NONNULL(2); +-- +2.23.0 + -- Gitee From 060a85b0c3d3a28c7d6d303a3840e7ba150f397b Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Thu, 11 Jun 2020 13:53:27 +0200 Subject: [PATCH 19/44] conf: Increase cpuset length limit for CPU pinning Domains are now allowed to be pinned to host CPUs with IDs up to 16383. The new limit is as arbitrary as the old one. It's just bigger. cherry-pick from commit: e728ffba5119cfb1488aa7363fef596940449f50 Signed-off-by: Jiri Denemark Reviewed-by: Michal Privoznik Signed-off-by: Jin Yan --- ...-cpuset-length-limit-for-CPU-pinning.patch | 33 +++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 conf-Increase-cpuset-length-limit-for-CPU-pinning.patch diff --git a/conf-Increase-cpuset-length-limit-for-CPU-pinning.patch b/conf-Increase-cpuset-length-limit-for-CPU-pinning.patch new file mode 100644 index 0000000..9033a40 --- /dev/null +++ b/conf-Increase-cpuset-length-limit-for-CPU-pinning.patch @@ -0,0 +1,33 @@ +From 45607ee0b646aa9d96fd886394018a00b2817559 Mon Sep 17 00:00:00 2001 +From: Jiri Denemark +Date: Thu, 11 Jun 2020 13:53:27 +0200 +Subject: [PATCH] conf: Increase cpuset length limit for CPU pinning + +Domains are now allowed to be pinned to host CPUs with IDs up to 16383. +The new limit is as arbitrary as the old one. It's just bigger. + +cherry-pick from commit: e728ffba5119cfb1488aa7363fef596940449f50 + +Signed-off-by: Jiri Denemark +Reviewed-by: Michal Privoznik +Signed-off-by: Jin Yan +--- + src/conf/domain_conf.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h +index a40773a0f4..16e625331c 100644 +--- a/src/conf/domain_conf.h ++++ b/src/conf/domain_conf.h +@@ -2241,7 +2241,7 @@ struct _virDomainHugePage { + unsigned long long size; /* hugepage size in KiB */ + }; + +-#define VIR_DOMAIN_CPUMASK_LEN 1024 ++#define VIR_DOMAIN_CPUMASK_LEN 16384 + + struct _virDomainIOThreadIDDef { + bool autofill; +-- +2.23.0 + -- Gitee From 3ae8d4b8a5c3d81b5881e9b46e66a66869a1b200 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Tue, 16 Jun 2020 12:36:55 +0200 Subject: [PATCH 20/44] virQEMUDriverConfigNew: Add slash to cfg->defaultTLSx509certdir for non-embedded driver Commit 068efae5b1a9ef accidentally removed the slash. https://bugzilla.redhat.com/show_bug.cgi?id=1847234 cherry-pick from commit: 8f58a4003532d5fffdadf2adc659c94eba3fa21a Signed-off-by: Peter Krempa Reviewed-by: Andrea Bolognani Signed-off-by: Jin Yan --- ...figNew-Add-slash-to-cfg-defaultTLSx5.patch | 35 +++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 virQEMUDriverConfigNew-Add-slash-to-cfg-defaultTLSx5.patch diff --git a/virQEMUDriverConfigNew-Add-slash-to-cfg-defaultTLSx5.patch b/virQEMUDriverConfigNew-Add-slash-to-cfg-defaultTLSx5.patch new file mode 100644 index 0000000..e79d6f2 --- /dev/null +++ b/virQEMUDriverConfigNew-Add-slash-to-cfg-defaultTLSx5.patch @@ -0,0 +1,35 @@ +From cd0cfebc813c7bde4725a80803339a887c2af6ba Mon Sep 17 00:00:00 2001 +From: Peter Krempa +Date: Tue, 16 Jun 2020 12:36:55 +0200 +Subject: [PATCH] virQEMUDriverConfigNew: Add slash to + cfg->defaultTLSx509certdir for non-embedded driver + +Commit 068efae5b1a9ef accidentally removed the slash. + +https://bugzilla.redhat.com/show_bug.cgi?id=1847234 + +cherry-pick from commit: 8f58a4003532d5fffdadf2adc659c94eba3fa21a + +Signed-off-by: Peter Krempa +Reviewed-by: Andrea Bolognani +Signed-off-by: Jin Yan +--- + src/qemu/qemu_conf.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c +index 15837cece4..809e8fe526 100644 +--- a/src/qemu/qemu_conf.c ++++ b/src/qemu/qemu_conf.c +@@ -234,7 +234,7 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool privileged, + * directory doesn't exist (although we don't check if this exists). + */ + if (root == NULL) { +- cfg->defaultTLSx509certdir = g_strdup(SYSCONFDIR "pki/qemu"); ++ cfg->defaultTLSx509certdir = g_strdup(SYSCONFDIR "/pki/qemu"); + } else { + cfg->defaultTLSx509certdir = g_strdup_printf("%s/etc/pki/qemu", root); + } +-- +2.23.0 + -- Gitee From b6712af6ef3590fbb65a8dc92bb9c7faca5cf263 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Thu, 11 Jun 2020 15:54:57 -0300 Subject: [PATCH 21/44] qemuDomainSetNumaParamsLive: set nodeset for root cgroup This function handles the change of NUMA nodeset for a given guest, setting CpusetMems for the emulator, vcpus and IOThread sub-groups. It doesn't set the same nodeset to the root cgroup though. This means that cpuset.mems of the root cgroup ends up holding the new nodeset and the old nodeset as well. For a guest with placement=strict, nodeset='0', doing virsh numatune 0 8 --live Will make cpuset.mems of emulator, vcpus and iothread to be "8", but cpuset.mems of the root cgroup will be "0,8". This means that any new tasks that ends up landing in the root cgroup, aside from the emulator/vcpus/iothread sub-groups, will be split between the old nodeset and the new nodeset, which is not what we want. cherry-pick from commit: 1b22dd6dd44202094e0f78f887cbe790c00e9ebc Signed-off-by: Daniel Henrique Barboza Reviewed-by: Michal Privoznik Signed-off-by: Jin Yan --- ...aParamsLive-set-nodeset-for-root-cgr.patch | 49 +++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 qemuDomainSetNumaParamsLive-set-nodeset-for-root-cgr.patch diff --git a/qemuDomainSetNumaParamsLive-set-nodeset-for-root-cgr.patch b/qemuDomainSetNumaParamsLive-set-nodeset-for-root-cgr.patch new file mode 100644 index 0000000..3e6313e --- /dev/null +++ b/qemuDomainSetNumaParamsLive-set-nodeset-for-root-cgr.patch @@ -0,0 +1,49 @@ +From 90ad71ea8aec0065558b918824729f32cac2578d Mon Sep 17 00:00:00 2001 +From: Daniel Henrique Barboza +Date: Thu, 11 Jun 2020 15:54:57 -0300 +Subject: [PATCH] qemuDomainSetNumaParamsLive: set nodeset for root cgroup + +This function handles the change of NUMA nodeset for a given +guest, setting CpusetMems for the emulator, vcpus and IOThread +sub-groups. It doesn't set the same nodeset to the root cgroup +though. This means that cpuset.mems of the root cgroup ends up +holding the new nodeset and the old nodeset as well. For +a guest with placement=strict, nodeset='0', doing + +virsh numatune 0 8 --live + +Will make cpuset.mems of emulator, vcpus and iothread to be +"8", but cpuset.mems of the root cgroup will be "0,8". + +This means that any new tasks that ends up landing in the +root cgroup, aside from the emulator/vcpus/iothread sub-groups, +will be split between the old nodeset and the new nodeset, +which is not what we want. + +cherry-pick from commit: 1b22dd6dd44202094e0f78f887cbe790c00e9ebc + +Signed-off-by: Daniel Henrique Barboza +Reviewed-by: Michal Privoznik +Signed-off-by: Jin Yan +--- + src/qemu/qemu_driver.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c +index 8bc5368b2f..cb049fe2ab 100644 +--- a/src/qemu/qemu_driver.c ++++ b/src/qemu/qemu_driver.c +@@ -9728,6 +9728,10 @@ qemuDomainSetNumaParamsLive(virDomainObjPtr vm, + virCgroupFree(&cgroup_temp); + } + ++ /* set nodeset for root cgroup */ ++ if (virCgroupSetCpusetMems(priv->cgroup, nodeset_str) < 0) ++ goto cleanup; ++ + ret = 0; + cleanup: + virCgroupFree(&cgroup_temp); +-- +2.23.0 + -- Gitee From 71cc2aefbf6c88b0d6cc02e5a3709f00aac6d953 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Tue, 16 Jun 2020 16:32:10 +0200 Subject: [PATCH 22/44] qemu: do not add model when actual iface type is hostdev No default model should be added to the interface entry at post parse when its actual network type is hostdev as doing so might cause a mismatch between the interface definition and its actual device type. cherry-pick from commit: bdb8f2e41867ae5dbcc040909b1b8c20fd864a40 Signed-off-by: Paulo de Rezende Pinatti Reviewed-by: Laine Stump Signed-off-by: Jin Yan --- ...model-when-actual-iface-type-is-host.patch | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 qemu-do-not-add-model-when-actual-iface-type-is-host.patch diff --git a/qemu-do-not-add-model-when-actual-iface-type-is-host.patch b/qemu-do-not-add-model-when-actual-iface-type-is-host.patch new file mode 100644 index 0000000..43778dc --- /dev/null +++ b/qemu-do-not-add-model-when-actual-iface-type-is-host.patch @@ -0,0 +1,34 @@ +From 2c405ee2378c8f51d0e5c6bd0430a35d7ca5aef8 Mon Sep 17 00:00:00 2001 +From: Paulo de Rezende Pinatti +Date: Tue, 16 Jun 2020 16:32:10 +0200 +Subject: [PATCH] qemu: do not add model when actual iface type is hostdev + +No default model should be added to the interface +entry at post parse when its actual network type is hostdev +as doing so might cause a mismatch between the interface +definition and its actual device type. + +cherry-pick from commit: bdb8f2e41867ae5dbcc040909b1b8c20fd864a40 + +Signed-off-by: Paulo de Rezende Pinatti +Reviewed-by: Laine Stump +Signed-off-by: Jin Yan +--- + src/qemu/qemu_domain.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c +index 91c1a49efa..cfada815b1 100644 +--- a/src/qemu/qemu_domain.c ++++ b/src/qemu/qemu_domain.c +@@ -9334,6 +9334,7 @@ qemuDomainDeviceNetDefPostParse(virDomainNetDefPtr net, + virQEMUCapsPtr qemuCaps) + { + if (net->type != VIR_DOMAIN_NET_TYPE_HOSTDEV && ++ virDomainNetResolveActualType(net) != VIR_DOMAIN_NET_TYPE_HOSTDEV && + !virDomainNetGetModelString(net)) + net->model = qemuDomainDefaultNetModel(def, qemuCaps); + +-- +2.23.0 + -- Gitee From 35da021985c23178f1435f81e21cc627e3482955 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Tue, 14 Jul 2020 15:44:05 +0800 Subject: [PATCH 23/44] qemu: pre-create the dbus directory in qemuStateInitialize MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit There are races condiction to make '/run/libvirt/qemu/dbus' directory in virDirCreateNoFork() while concurrent start VMs, and get "failed to create directory '/run/libvirt/qemu/dbus': File exists" error message. pre-create the dbus directory in qemuStateInitialize. Signed-off-by: Bihong Yu Reviewed-by: Ján Tomko Signed-off-by: Ján Tomko --- ...the-dbus-directory-in-qemuStateIniti.patch | 92 +++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 qemu-pre-create-the-dbus-directory-in-qemuStateIniti.patch diff --git a/qemu-pre-create-the-dbus-directory-in-qemuStateIniti.patch b/qemu-pre-create-the-dbus-directory-in-qemuStateIniti.patch new file mode 100644 index 0000000..7e329f1 --- /dev/null +++ b/qemu-pre-create-the-dbus-directory-in-qemuStateIniti.patch @@ -0,0 +1,92 @@ +From a55209972b92588e0a57937a6ff9c8f58592fd20 Mon Sep 17 00:00:00 2001 +From: Bihong Yu +Date: Tue, 14 Jul 2020 15:44:05 +0800 +Subject: [PATCH] qemu: pre-create the dbus directory in qemuStateInitialize +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +There are races condiction to make '/run/libvirt/qemu/dbus' directory in +virDirCreateNoFork() while concurrent start VMs, and get "failed to create +directory '/run/libvirt/qemu/dbus': File exists" error message. pre-create the +dbus directory in qemuStateInitialize. + +Signed-off-by: Bihong Yu +Reviewed-by: Ján Tomko +Signed-off-by: Ján Tomko +--- + src/qemu/qemu_dbus.c | 10 ---------- + src/qemu/qemu_dbus.h | 2 -- + src/qemu/qemu_driver.c | 7 +++++++ + src/qemu/qemu_process.c | 3 --- + 4 files changed, 7 insertions(+), 15 deletions(-) + +diff --git a/src/qemu/qemu_dbus.c b/src/qemu/qemu_dbus.c +index f3e6f3ee37..d1cef4cbc3 100644 +--- a/src/qemu/qemu_dbus.c ++++ b/src/qemu/qemu_dbus.c +@@ -33,16 +33,6 @@ + VIR_LOG_INIT("qemu.dbus"); + + +-int +-qemuDBusPrepareHost(virQEMUDriverPtr driver) +-{ +- g_autoptr(virQEMUDriverConfig) cfg = virQEMUDriverGetConfig(driver); +- +- return virDirCreate(cfg->dbusStateDir, 0770, cfg->user, cfg->group, +- VIR_DIR_CREATE_ALLOW_EXIST); +-} +- +- + static char * + qemuDBusCreatePidFilename(virQEMUDriverConfigPtr cfg, + const char *shortName) +diff --git a/src/qemu/qemu_dbus.h b/src/qemu/qemu_dbus.h +index a96f19ac0d..a65d52caea 100644 +--- a/src/qemu/qemu_dbus.h ++++ b/src/qemu/qemu_dbus.h +@@ -21,8 +21,6 @@ + #include "qemu_conf.h" + #include "qemu_domain.h" + +-int qemuDBusPrepareHost(virQEMUDriverPtr driver); +- + char *qemuDBusGetAddress(virQEMUDriverPtr driver, + virDomainObjPtr vm); + +diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c +index cb049fe2ab..c8af44b738 100644 +--- a/src/qemu/qemu_driver.c ++++ b/src/qemu/qemu_driver.c +@@ -749,6 +749,13 @@ qemuStateInitialize(bool privileged, + goto error; + } + ++ if (virDirCreate(cfg->dbusStateDir, 0770, cfg->user, cfg->group, ++ VIR_DIR_CREATE_ALLOW_EXIST) < 0) { ++ virReportSystemError(errno, _("Failed to create dbus state dir %s"), ++ cfg->dbusStateDir); ++ goto error; ++ } ++ + if ((qemu_driver->lockFD = + virPidFileAcquire(cfg->stateDir, "driver", false, getpid())) < 0) + goto error; +diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c +index 280fed932a..9cf7242f31 100644 +--- a/src/qemu/qemu_process.c ++++ b/src/qemu/qemu_process.c +@@ -6481,9 +6481,6 @@ qemuProcessPrepareHost(virQEMUDriverPtr driver, + qemuDomainObjPrivatePtr priv = vm->privateData; + g_autoptr(virQEMUDriverConfig) cfg = virQEMUDriverGetConfig(driver); + +- if (qemuDBusPrepareHost(driver) < 0) +- return -1; +- + if (qemuPrepareNVRAM(cfg, vm) < 0) + return -1; + +-- +2.23.0 + -- Gitee From 4f21704e9d41cd66e5c2f23ff7ad354762820130 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Thu, 18 Jun 2020 12:49:09 -0400 Subject: [PATCH 24/44] conf, vmx: check for OOM after calling xmlBufferCreate() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Although libvirt itself uses g_malloc0() and friends, which exit when there isn't enouogh memory, libxml2 uses standard malloc(), which just returns NULL on OOM - this means we must check for NULL on return from any libxml2 functions that allocate memory. xmlBufferCreate(), for example, might return NULL, and we don't always check for it. This patch adds checks where it isn't already done. (NB: Although libxml2 has a provision for changing behavior on OOM (by calling xmlMemSetup() to change what functions are used to allocating/freeing memory), we can't use that, since parts of libvirt code end up in libvirt.so, which is linked and called directly by applications that may themselves use libxml2 (and may have already set their own alternate malloc()), e.g. drivers like esx which live totally in the library rather than a separate process.) cherry pick from: b7a92bce070fd57844a59bf8b1c30cb4ef4f3acd Signed-off-by: Laine Stump Reviewed-by: Ján Tomko --- ...or-OOM-after-calling-xmlBufferCreate.patch | 100 ++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 conf-vmx-check-for-OOM-after-calling-xmlBufferCreate.patch diff --git a/conf-vmx-check-for-OOM-after-calling-xmlBufferCreate.patch b/conf-vmx-check-for-OOM-after-calling-xmlBufferCreate.patch new file mode 100644 index 0000000..f1caef4 --- /dev/null +++ b/conf-vmx-check-for-OOM-after-calling-xmlBufferCreate.patch @@ -0,0 +1,100 @@ +From e2c3676e4a44ee3ca4b0f9f3c1a9c4e919facdd9 Mon Sep 17 00:00:00 2001 +From: Laine Stump +Date: Thu, 18 Jun 2020 12:49:09 -0400 +Subject: [PATCH] conf, vmx: check for OOM after calling xmlBufferCreate() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Although libvirt itself uses g_malloc0() and friends, which exit when +there isn't enouogh memory, libxml2 uses standard malloc(), which just +returns NULL on OOM - this means we must check for NULL on return from +any libxml2 functions that allocate memory. + +xmlBufferCreate(), for example, might return NULL, and we don't always +check for it. This patch adds checks where it isn't already done. + +(NB: Although libxml2 has a provision for changing behavior on OOM (by +calling xmlMemSetup() to change what functions are used to +allocating/freeing memory), we can't use that, since parts of libvirt +code end up in libvirt.so, which is linked and called directly by +applications that may themselves use libxml2 (and may have already set +their own alternate malloc()), e.g. drivers like esx which live totally +in the library rather than a separate process.) + +cherry pick from: b7a92bce070fd57844a59bf8b1c30cb4ef4f3acd + +Signed-off-by: Laine Stump +Reviewed-by: Ján Tomko +--- + src/conf/domain_conf.c | 6 +++++- + src/conf/network_conf.c | 6 +++++- + src/vmx/vmx.c | 11 +++++++---- + 3 files changed, 17 insertions(+), 6 deletions(-) + +diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c +index 6192c08545..c51c613673 100644 +--- a/src/conf/domain_conf.c ++++ b/src/conf/domain_conf.c +@@ -29027,7 +29027,11 @@ virDomainDefFormatInternalSetRootName(virDomainDefPtr def, + * Thankfully, libxml maps what looks like globals into + * thread-local uses, so we are thread-safe. */ + xmlIndentTreeOutput = 1; +- xmlbuf = xmlBufferCreate(); ++ if (!(xmlbuf = xmlBufferCreate())) { ++ virReportOOMError(); ++ goto error; ++ } ++ + if (xmlNodeDump(xmlbuf, def->metadata->doc, def->metadata, + virBufferGetIndent(buf) / 2, 1) < 0) { + xmlBufferFree(xmlbuf); +diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c +index 819b645df7..c379042241 100644 +--- a/src/conf/network_conf.c ++++ b/src/conf/network_conf.c +@@ -2478,7 +2478,11 @@ virNetworkDefFormatBuf(virBufferPtr buf, + * Thankfully, libxml maps what looks like globals into + * thread-local uses, so we are thread-safe. */ + xmlIndentTreeOutput = 1; +- xmlbuf = xmlBufferCreate(); ++ if (!(xmlbuf = xmlBufferCreate())) { ++ virReportOOMError(); ++ return -1; ++ } ++ + if (xmlNodeDump(xmlbuf, def->metadata->doc, def->metadata, + virBufferGetIndent(buf) / 2, 1) < 0) { + xmlBufferFree(xmlbuf); +diff --git a/src/vmx/vmx.c b/src/vmx/vmx.c +index b1fd1181eb..fbc8366f2b 100644 +--- a/src/vmx/vmx.c ++++ b/src/vmx/vmx.c +@@ -697,8 +697,8 @@ virVMXConvertToUTF8(const char *encoding, const char *string) + { + char *result = NULL; + xmlCharEncodingHandlerPtr handler; +- xmlBufferPtr input; +- xmlBufferPtr utf8; ++ xmlBufferPtr input = NULL; ++ xmlBufferPtr utf8 = NULL; + + handler = xmlFindCharEncodingHandler(encoding); + +@@ -708,8 +708,11 @@ virVMXConvertToUTF8(const char *encoding, const char *string) + return NULL; + } + +- input = xmlBufferCreateStatic((char *)string, strlen(string)); +- utf8 = xmlBufferCreate(); ++ if (!(input = xmlBufferCreateStatic((char *)string, strlen(string))) || ++ !(utf8 = xmlBufferCreate())) { ++ virReportOOMError(); ++ goto cleanup; ++ } + + if (xmlCharEncInFunc(handler, utf8, input) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, +-- +2.23.0 + -- Gitee From 66ef48700c9e305959745f0271370ee26fa3af47 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Thu, 11 Jun 2020 16:43:22 +0200 Subject: [PATCH 25/44] leaseshelper: Wait to acquire PID file MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On a DHCP transaction, dnsmasq runs our leases helper which updates corresponding JSON files. While one dnsmasq won't run the leaseshelper in parallel, two dnsmasqs (from two distinct networks) might. To avoid corrupting JSON file, the leaseshelper acquires PID file first. Well, the way it's acquiring it is not ideal - it calls virPidFileAcquirePath(wait = false); which means, that either it acquires the PID file instantly or returns an error and does not touch the JSON at all. This in turn means that there might be a leases record missing. With wait = true, this won't happen. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1840307 cherry pick from: 876211ef4a192df1603b45715044ec14567d7e9f Signed-off-by: Michal Privoznik Reviewed-by: Daniel P. Berrangé --- leaseshelper-Wait-to-acquire-PID-file.patch | 45 +++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 leaseshelper-Wait-to-acquire-PID-file.patch diff --git a/leaseshelper-Wait-to-acquire-PID-file.patch b/leaseshelper-Wait-to-acquire-PID-file.patch new file mode 100644 index 0000000..c8ada65 --- /dev/null +++ b/leaseshelper-Wait-to-acquire-PID-file.patch @@ -0,0 +1,45 @@ +From ec9da8b78bbfcc77ed14739d10464cb350b6054f Mon Sep 17 00:00:00 2001 +From: Michal Privoznik +Date: Thu, 11 Jun 2020 16:43:22 +0200 +Subject: [PATCH] leaseshelper: Wait to acquire PID file +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +On a DHCP transaction, dnsmasq runs our leases helper which +updates corresponding JSON files. While one dnsmasq won't run the +leaseshelper in parallel, two dnsmasqs (from two distinct +networks) might. To avoid corrupting JSON file, the leaseshelper +acquires PID file first. Well, the way it's acquiring it is not +ideal - it calls virPidFileAcquirePath(wait = false); which +means, that either it acquires the PID file instantly or returns +an error and does not touch the JSON at all. This in turn means +that there might be a leases record missing. With wait = true, +this won't happen. + +Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1840307 + +cherry pick from: 876211ef4a192df1603b45715044ec14567d7e9f + +Signed-off-by: Michal Privoznik +Reviewed-by: Daniel P. Berrangé +--- + src/network/leaseshelper.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/network/leaseshelper.c b/src/network/leaseshelper.c +index a1780ca4e4..86c847db6d 100644 +--- a/src/network/leaseshelper.c ++++ b/src/network/leaseshelper.c +@@ -160,7 +160,7 @@ main(int argc, char **argv) + pid_file = g_strdup(RUNSTATEDIR "/leaseshelper.pid"); + + /* Try to claim the pidfile, exiting if we can't */ +- if ((pid_file_fd = virPidFileAcquirePath(pid_file, false, getpid())) < 0) ++ if ((pid_file_fd = virPidFileAcquirePath(pid_file, true, getpid())) < 0) + goto cleanup; + + /* Since interfaces can be hot plugged, we need to make sure that the +-- +2.23.0 + -- Gitee From 5c18fcc4c5531bc4009977dd401edeef1e826b82 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Mon, 15 Jun 2020 12:53:48 +0200 Subject: [PATCH 26/44] leaseshelper: Report more errors MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Some functions or code paths that may fail don't report error (e.g. when acquiring PID file fails) leading to a silent quit of the leaseshelper. This makes it super hard for us and users to debug what is happening. Fortunately, dnsmasq captures both stdout and stderr so we can write an error message there. cherry pick from: 9ed345ac1a035c8cf1de37431de638f4bac41de3 Signed-off-by: Michal Privoznik Reviewed-by: Daniel P. Berrangé --- leaseshelper-Report-more-errors.patch | 66 +++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 leaseshelper-Report-more-errors.patch diff --git a/leaseshelper-Report-more-errors.patch b/leaseshelper-Report-more-errors.patch new file mode 100644 index 0000000..b98f9ab --- /dev/null +++ b/leaseshelper-Report-more-errors.patch @@ -0,0 +1,66 @@ +From 49c31f5015f9d31f57a0088e320f577f5e495275 Mon Sep 17 00:00:00 2001 +From: Michal Privoznik +Date: Mon, 15 Jun 2020 12:53:48 +0200 +Subject: [PATCH] leaseshelper: Report more errors +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Some functions or code paths that may fail don't report error +(e.g. when acquiring PID file fails) leading to a silent quit +of the leaseshelper. This makes it super hard for us and users +to debug what is happening. Fortunately, dnsmasq captures both +stdout and stderr so we can write an error message there. + +cherry pick from: 9ed345ac1a035c8cf1de37431de638f4bac41de3 + +Signed-off-by: Michal Privoznik +Reviewed-by: Daniel P. Berrangé +--- + src/network/leaseshelper.c | 18 ++++++++++++++---- + 1 file changed, 14 insertions(+), 4 deletions(-) + +diff --git a/src/network/leaseshelper.c b/src/network/leaseshelper.c +index 86c847db6d..2b5fc0f442 100644 +--- a/src/network/leaseshelper.c ++++ b/src/network/leaseshelper.c +@@ -131,8 +131,10 @@ main(int argc, char **argv) + * events for expired leases. So, libvirtd sets another env var for this + * purpose */ + if (!interface && +- !(interface = getenv("VIR_BRIDGE_NAME"))) +- goto cleanup; ++ !(interface = getenv("VIR_BRIDGE_NAME"))) { ++ fprintf(stderr, _("interface not set\n")); ++ exit(EXIT_FAILURE); ++ } + + ip = argv[3]; + mac = argv[2]; +@@ -160,13 +162,21 @@ main(int argc, char **argv) + pid_file = g_strdup(RUNSTATEDIR "/leaseshelper.pid"); + + /* Try to claim the pidfile, exiting if we can't */ +- if ((pid_file_fd = virPidFileAcquirePath(pid_file, true, getpid())) < 0) ++ if ((pid_file_fd = virPidFileAcquirePath(pid_file, true, getpid())) < 0) { ++ fprintf(stderr, ++ _("Unable to acquire PID file: %s\n errno=%d"), ++ pid_file, errno); + goto cleanup; ++ } + + /* Since interfaces can be hot plugged, we need to make sure that the + * corresponding custom lease file exists. If not, 'touch' it */ +- if (virFileTouch(custom_lease_file, 0644) < 0) ++ if (virFileTouch(custom_lease_file, 0644) < 0) { ++ fprintf(stderr, ++ _("Unable to create: %s\n errno=%d"), ++ custom_lease_file, errno); + goto cleanup; ++ } + + switch ((enum virLeaseActionFlags) action) { + case VIR_LEASE_ACTION_ADD: +-- +2.23.0 + -- Gitee From 8732ac5fb90c938b97e86c40ad703c687aa61605 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Wed, 8 Jul 2020 09:13:42 +0200 Subject: [PATCH 27/44] qemuBuildMemoryBackendProps: Use boolean type for 'pmem' property MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Commit 82576d8f35e used a string "on" to enable the 'pmem' property. This is okay for the command line visitor, but the property is declared as boolean in qemu and thus it will not work when using QMP. Modify the type to boolean. This changes the command line, but fortunately the command line visitor in qemu parses both 'yes' and 'on' as true for the property. https://bugzilla.redhat.com/show_bug.cgi?id=1854684 cherry pick from: e95da4e5bf53ff977f440903df9f7343f2fb6f0e Signed-off-by: Peter Krempa Reviewed-by: Ján Tomko --- ...ackendProps-Use-boolean-type-for-pme.patch | 57 +++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 qemuBuildMemoryBackendProps-Use-boolean-type-for-pme.patch diff --git a/qemuBuildMemoryBackendProps-Use-boolean-type-for-pme.patch b/qemuBuildMemoryBackendProps-Use-boolean-type-for-pme.patch new file mode 100644 index 0000000..498033c --- /dev/null +++ b/qemuBuildMemoryBackendProps-Use-boolean-type-for-pme.patch @@ -0,0 +1,57 @@ +From 4c1e37f7685c0aaf8e0aad65a38606ec7c710bf4 Mon Sep 17 00:00:00 2001 +From: Peter Krempa +Date: Wed, 8 Jul 2020 09:13:42 +0200 +Subject: [PATCH] qemuBuildMemoryBackendProps: Use boolean type for 'pmem' + property +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Commit 82576d8f35e used a string "on" to enable the 'pmem' property. +This is okay for the command line visitor, but the property is declared +as boolean in qemu and thus it will not work when using QMP. + +Modify the type to boolean. This changes the command line, but +fortunately the command line visitor in qemu parses both 'yes' and 'on' +as true for the property. + +https://bugzilla.redhat.com/show_bug.cgi?id=1854684 + +cherry pick from: e95da4e5bf53ff977f440903df9f7343f2fb6f0e + +Signed-off-by: Peter Krempa +Reviewed-by: Ján Tomko +--- + src/qemu/qemu_command.c | 2 +- + .../memory-hotplug-nvdimm-pmem.x86_64-latest.args | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c +index 2f65b8ddc6..315deb5cfd 100644 +--- a/src/qemu/qemu_command.c ++++ b/src/qemu/qemu_command.c +@@ -3523,7 +3523,7 @@ qemuBuildMemoryBackendProps(virJSONValuePtr *backendProps, + "with this QEMU binary")); + return -1; + } +- if (virJSONValueObjectAdd(props, "s:pmem", "on", NULL) < 0) ++ if (virJSONValueObjectAdd(props, "b:pmem", true, NULL) < 0) + return -1; + } + +diff --git a/tests/qemuxml2argvdata/memory-hotplug-nvdimm-pmem.x86_64-latest.args b/tests/qemuxml2argvdata/memory-hotplug-nvdimm-pmem.x86_64-latest.args +index 5dfba9b50a..00a78baa92 100644 +--- a/tests/qemuxml2argvdata/memory-hotplug-nvdimm-pmem.x86_64-latest.args ++++ b/tests/qemuxml2argvdata/memory-hotplug-nvdimm-pmem.x86_64-latest.args +@@ -19,7 +19,7 @@ file=/tmp/lib/domain--1-QEMUGuest1/master-key.aes \ + -smp 2,sockets=2,dies=1,cores=1,threads=1 \ + -numa node,nodeid=0,cpus=0-1,mem=214 \ + -object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/tmp/nvdimm,\ +-share=no,size=536870912,pmem=on \ ++share=no,size=536870912,pmem=yes \ + -device nvdimm,node=0,memdev=memnvdimm0,id=nvdimm0,slot=0 \ + -uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \ + -display none \ +-- +2.23.0 + -- Gitee From 08bca108c02fea5fd23a01fe98fcc7d764a706e0 Mon Sep 17 00:00:00 2001 From: "Huawei Technologies Co., Ltd" Date: Tue, 23 Jun 2020 13:29:56 -0500 Subject: [PATCH 28/44] qemu: format 'ramfb' attribute for mediated devices MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit It's possible to use ramfb as the boot display of an assigned vgpu device. This was introduced in 4b95738c, but unfortunately the attribute was not formatted into the xml output for such a device. This patch fixes that oversight and adds a xml2xml test to verify proper behavior. https://bugzilla.redhat.com/show_bug.cgi?id=1847791 cherry pick from: c5815b31976f3982d18c7f6c1367ab6e403eb7eb Signed-off-by: Jonathon Jongsma Reviewed-by: Daniel Henrique Barboza Signed-off-by: Ján Tomko Reviewed-by: Ján Tomko --- ...ramfb-attribute-for-mediated-devices.patch | 107 ++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 qemu-format-ramfb-attribute-for-mediated-devices.patch diff --git a/qemu-format-ramfb-attribute-for-mediated-devices.patch b/qemu-format-ramfb-attribute-for-mediated-devices.patch new file mode 100644 index 0000000..33b9453 --- /dev/null +++ b/qemu-format-ramfb-attribute-for-mediated-devices.patch @@ -0,0 +1,107 @@ +From 710d16a2012c0ad134daae87838d85e9d4cb2330 Mon Sep 17 00:00:00 2001 +From: Jonathon Jongsma +Date: Tue, 23 Jun 2020 13:29:56 -0500 +Subject: [PATCH] qemu: format 'ramfb' attribute for mediated devices +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +It's possible to use ramfb as the boot display of an assigned vgpu +device. This was introduced in 4b95738c, but unfortunately the attribute +was not formatted into the xml output for such a device. This patch +fixes that oversight and adds a xml2xml test to verify proper behavior. + +https://bugzilla.redhat.com/show_bug.cgi?id=1847791 + +cherry pick from: c5815b31976f3982d18c7f6c1367ab6e403eb7eb + +Signed-off-by: Jonathon Jongsma +Reviewed-by: Daniel Henrique Barboza +Signed-off-by: Ján Tomko +Reviewed-by: Ján Tomko +--- + src/conf/domain_conf.c | 3 ++ + ...stdev-mdev-display-ramfb.x86_64-latest.xml | 44 +++++++++++++++++++ + tests/qemuxml2xmltest.c | 1 + + 3 files changed, 48 insertions(+) + create mode 100644 tests/qemuxml2xmloutdata/hostdev-mdev-display-ramfb.x86_64-latest.xml + +diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c +index c51c613673..dbc3e103ff 100644 +--- a/src/conf/domain_conf.c ++++ b/src/conf/domain_conf.c +@@ -27854,6 +27854,9 @@ virDomainHostdevDefFormat(virBufferPtr buf, + if (mdevsrc->display != VIR_TRISTATE_SWITCH_ABSENT) + virBufferAsprintf(buf, " display='%s'", + virTristateSwitchTypeToString(mdevsrc->display)); ++ if (mdevsrc->ramfb != VIR_TRISTATE_SWITCH_ABSENT) ++ virBufferAsprintf(buf, " ramfb='%s'", ++ virTristateSwitchTypeToString(mdevsrc->ramfb)); + } + + } +diff --git a/tests/qemuxml2xmloutdata/hostdev-mdev-display-ramfb.x86_64-latest.xml b/tests/qemuxml2xmloutdata/hostdev-mdev-display-ramfb.x86_64-latest.xml +new file mode 100644 +index 0000000000..c134400486 +--- /dev/null ++++ b/tests/qemuxml2xmloutdata/hostdev-mdev-display-ramfb.x86_64-latest.xml +@@ -0,0 +1,44 @@ ++ ++ QEMUGuest2 ++ c7a5fdbd-edaf-9455-926a-d65c16db1809 ++ 219136 ++ 219136 ++ 1 ++ ++ hvm ++ ++ ++ ++ qemu64 ++ ++ ++ destroy ++ restart ++ destroy ++ ++ /usr/bin/qemu-system-i386 ++ ++
++ ++ ++ ++
++ ++ ++ ++ ++ ++ ++