- Devel - libvirt List Archives

[PATCH] qemu_process: Separate VIR_PERF_EVENT_* setting into a function
by Michal Privoznik 07 Sep '20

07 Sep '20

When starting a domain, qemuProcessLaunch() iterates over all VIR_PERF_EVENT_* values and (possibly) enables them. While there is nothing wrong with the code, the for loop where its done makes it harder to jump onto next block of code. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Is this trivial enough to be pushed as such? src/qemu/qemu_process.c | 29 +++++++++++++++++++++-------- 1 file changed, 21 insertions(+), 8 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 6b1644880a..dd60fb0ddf 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -6700,6 +6700,25 @@ qemuProcessEnableDomainNamespaces(virQEMUDriverPtr driver, } +static int +qemuProcessEnablePerf(virDomainObjPtr vm) +{ + qemuDomainObjPrivatePtr priv = vm->privateData; + size_t i; + + if (!(priv->perf = virPerfNew())) + return -1; + + for (i = 0; i < VIR_PERF_EVENT_LAST; i++) { + if (vm->def->perf.events[i] == VIR_TRISTATE_BOOL_YES && + virPerfEventEnable(priv->perf, i, vm->pid) < 0) + return -1; + } + + return 0; +} + + /** * qemuProcessLaunch: * @@ -6733,7 +6752,6 @@ qemuProcessLaunch(virConnectPtr conn, g_autoptr(virQEMUDriverConfig) cfg = NULL; size_t nnicindexes = 0; g_autofree int *nicindexes = NULL; - size_t i; VIR_DEBUG("conn=%p driver=%p vm=%p name=%s if=%d asyncJob=%d " "incoming.launchURI=%s incoming.deferredURI=%s " @@ -6885,15 +6903,10 @@ qemuProcessLaunch(virConnectPtr conn, if (qemuSetupCgroup(vm, nnicindexes, nicindexes) < 0) goto cleanup; - if (!(priv->perf = virPerfNew())) + VIR_DEBUG("Setting up domain perf (if required)"); + if (qemuProcessEnablePerf(vm) < 0) goto cleanup; - for (i = 0; i < VIR_PERF_EVENT_LAST; i++) { - if (vm->def->perf.events[i] == VIR_TRISTATE_BOOL_YES && - virPerfEventEnable(priv->perf, i, vm->pid) < 0) - goto cleanup; - } - /* This must be done after cgroup placement to avoid resetting CPU * affinity */ if (qemuProcessInitCpuAffinity(vm) < 0) -- 2.26.2

2 1

[RFC PATCH] docs/system/deprecated: mark ppc64abi32-linux-user for deprecation
by Alex Bennée 07 Sep '20

07 Sep '20

It's buggy and we are not sure anyone uses it. Cc: David Gibson <david(a)gibson.dropbear.id.au> Cc: Richard Henderson <rth(a)twiddle.net> Signed-off-by: Alex Bennée <alex.bennee(a)linaro.org> --- docs/system/deprecated.rst | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst index 851dbdeb8ab..11c763383d9 100644 --- a/docs/system/deprecated.rst +++ b/docs/system/deprecated.rst @@ -424,6 +424,15 @@ linux-user mode) is deprecated and will be removed in a future version of QEMU. Support for this CPU was removed from the upstream Linux kernel in 2018, and has also been dropped from glibc. +``ppc64abi32`` CPUs (since 5.2.0) +''''''''''''''''''''''''''''''''' + +The ``ppc64abi32`` architecture has a number of issues which regularly +trip up our CI testing and is suspected to be quite broken. +Furthermore the maintainers are unsure what the correct behaviour +should be and strongly suspect no one actually uses it. + + Related binaries ---------------- -- 2.20.1

4 6

[PATCH] news: add 1 improvement for v6.6.0
by Yanqiu Zhang 07 Sep '20

07 Sep '20

Support TLS for NBD connections for pull mode backup. Signed-off-by: Yanqiu Zhang <yanqzhan(a)redhat.com> --- NEWS.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index e4b71e6563..d0b16e28fc 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -161,6 +161,12 @@ v6.6.0 (2020-08-02) The secret key used for disks can now be encrypted similarly to TLS keys used for migration, chardev and others. + * qemu: Support TLS for NBD connections for pull mode backup + + Use the configured TLS env to setup encryption of the TLS transport. Add 'tls' + attribute for 'server' element to enable tls. Possible values are ``yes`` + or ``no``. + * qemu: ``VIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLD`` can now be registered for ``<mirror>`` The event can now be used also for block copy destinations by using the -- 2.25.4

4 7

[PATCH] Revert "news: qemu: Support TLS for NBD connections for pull mode backup"
by Peter Krempa 07 Sep '20

07 Sep '20

Incremental backups are not enabled. There's no point documenting individual patches implementing an incomplete feature. This reverts commit e6285f84faeacccdef12b69a7bc38975230d6662. --- NEWS.rst | 6 ------ 1 file changed, 6 deletions(-) diff --git a/NEWS.rst b/NEWS.rst index 008a6358c6..14f098b1f6 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -167,12 +167,6 @@ v6.6.0 (2020-08-02) The secret key used for disks can now be encrypted similarly to TLS keys used for migration, chardev and others. - * qemu: Support TLS for NBD connections for pull mode backup - - Use the configured TLS env to setup encryption of the TLS transport. Add - 'tls' attribute for 'server' element to enable TLS. Possible values are - ``yes`` or ``no``. - * qemu: ``VIR_DOMAIN_EVENT_ID_BLOCK_THRESHOLD`` can now be registered for ``<mirror>`` The event can now be used also for block copy destinations by using the -- 2.26.2

3 2

[libvirt PATCH] wireshark: Don't include config.h
by Andrea Bolognani 07 Sep '20

07 Sep '20

While both Debian and Fedora include the header in their development packages for Wireshark, that's not something that the upstream developers intended and arguably quite wrong, as config.h is obviously intended to only be used to drive the compilation of Wireshark itself. The Arch Linux package behaves like the upstream Wireshark package, and thus libvirt fails to build there. It seems that there are multiple bugs to be addressed: * libvirt shouldn't include config.h; * Debian and Fedora shouldn't be shipping config.h in their Wireshark packages; * Wireshark should not use config.h defines such as HAVE_PLUGINS in its public headers, and define a public variant of them instead. This patch takes care of the first one. https://gitlab.com/libvirt/libvirt/-/issues/74 Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- tools/wireshark/src/packet-libvirt.c | 1 - tools/wireshark/src/plugin.c | 13 +++++++------ 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/tools/wireshark/src/packet-libvirt.c b/tools/wireshark/src/packet-libvirt.c index 9f3c7f650d..965f1f5482 100644 --- a/tools/wireshark/src/packet-libvirt.c +++ b/tools/wireshark/src/packet-libvirt.c @@ -18,7 +18,6 @@ */ #include <config.h> -#include <wireshark/config.h> #include <wireshark/epan/proto.h> #include <wireshark/epan/packet.h> #include <wireshark/epan/dissectors/packet-tcp.h> diff --git a/tools/wireshark/src/plugin.c b/tools/wireshark/src/plugin.c index 504e4383a7..3c6fae9ef5 100644 --- a/tools/wireshark/src/plugin.c +++ b/tools/wireshark/src/plugin.c @@ -14,11 +14,12 @@ #include <gmodule.h> -#include <wireshark/config.h> +#define HAVE_PLUGINS 1 #include <wireshark/epan/proto.h> /* plugins are DLLs */ #define WS_BUILD_DLL #include <wireshark/ws_symbol_export.h> +#include <wireshark/ws_version.h> #include "packet-libvirt.h" @@ -26,9 +27,9 @@ #define PLUGIN_VERSION VERSION #define WIRESHARK_VERSION \ - ((VERSION_MAJOR * 1000 * 1000) + \ - (VERSION_MINOR * 1000) + \ - (VERSION_MICRO)) + ((WIRESHARK_VERSION_MAJOR * 1000 * 1000) + \ + (WIRESHARK_VERSION_MINOR * 1000) + \ + (WIRESHARK_VERSION_MICRO)) #if WIRESHARK_VERSION < 2005000 @@ -69,8 +70,8 @@ void proto_register_libvirt(void); void proto_reg_handoff_libvirt(void); WS_DLL_PUBLIC_DEF const gchar plugin_version[] = PLUGIN_VERSION; -WS_DLL_PUBLIC_DEF const int plugin_want_major = VERSION_MAJOR; -WS_DLL_PUBLIC_DEF const int plugin_want_minor = VERSION_MINOR; +WS_DLL_PUBLIC_DEF const int plugin_want_major = WIRESHARK_VERSION_MAJOR; +WS_DLL_PUBLIC_DEF const int plugin_want_minor = WIRESHARK_VERSION_MINOR; WS_DLL_PUBLIC void plugin_register(void); -- 2.26.2

3 8

[libvirt PATCH 0/2] Fix IPv6 network startup after removal of "dummy" tap device
by Laine Stump 07 Sep '20

07 Sep '20

After the patch that removed the dummy tap device was added (commit ee6c936fbb), IPv6 networks would no longer start due to a "failure to complete DAD". Since this wait was only necessary because of the existence of the dummy tap device (see detailed git log spelunking in Patch 1 comment), we can just remove the wait. Laine Stump (2): network: don't wait for IPv6 DAD completion when starting a network util: remove unused virNetDevIPWaitDadFinish() src/libvirt_private.syms | 1 - src/network/bridge_driver.c | 32 ---------- src/util/virnetdevip.c | 119 ------------------------------------ src/util/virnetdevip.h | 2 - 4 files changed, 154 deletions(-) -- 2.26.2

3 4

watchdog fed successfully event of 6300esb
by ligang (P) 07 Sep '20

07 Sep '20

Hi folks, I have an question to discuss about the 6300esb watchdog. I think is it possible that qemu can send an event while the watchdog successfully fed by the vm at the first time. Here is the situation: Qemu will send an VIR_DOMAIN_EVENT_ID_WATCHDOG event while watch dog timeout, and if the action of the watchdog in xml of the vm was set to "reset", the vm will be rebooted while timeout. I have an monitor process that register callback function of the VIR_DOMAIN_EVENT_ID_WATCHDOG event, the callback function will send an alarm to my upper layer monitor platform indicate that the vm is fault, and the cluster deployed business on the vm will isolate the vm by the alarm. And after the vm rebooted , the monitor process will receive an reboot event and send it to the platform, the upper layer monitor platform will clear the alarm, and business continue to run on the vm. In most cases ,the watch dog process in vm will feed the watchdog after vm rebooted and all things go back on track. In some other cases,the guestos may failed to start (in my environment vm start failed by io error), but the reboot event will still be received and the alarm will be cleared and the vm is still fault. So the this may not a good idea to clear the alarm by the reboot event. So, I think it will be helpful that the qemu can send an event while the watchdog successfully fed by the vm at the first time. So I can exactly know that the guest os go back on running and the watch dog initialized successfully. Or any other opintion about this situation. Thanks.

1 0

[PATCH v2] qemu_namespace: Don't leak mknod items that are being skipped over
by Michal Privoznik 07 Sep '20

07 Sep '20

When building and populating domain NS a couple of functions are called that append paths to a string list. This string list is then inspected, one item at the time by qemuNamespacePrepareOneItem() which gathers all the info for given path (stat buffer, possible link target, ACLs, SELinux label) using qemuNamespaceMknodItemInit(). If the path needs to be created in the domain's private /dev then it's added onto this qemuNamespaceMknodData list which is freed later in the process. But, if the path does not need to be created in the domain's private /dev, then the memory allocated by qemuNamespaceMknodItemInit() is not freed anywhere leading to a leak. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- v2 of: https://www.redhat.com/archives/libvir-list/2020-September/msg00248.html diff to v2: - autocleanup approach is implemented in qemuNamespacePrepareOneItem() src/qemu/qemu_namespace.c | 31 +++++++++++++++++++++---------- 1 file changed, 21 insertions(+), 10 deletions(-) diff --git a/src/qemu/qemu_namespace.c b/src/qemu/qemu_namespace.c index 87f4fd8d58..b0d1d0d083 100644 --- a/src/qemu/qemu_namespace.c +++ b/src/qemu/qemu_namespace.c @@ -871,7 +871,7 @@ qemuDomainNamespaceAvailable(qemuDomainNamespace ns G_GNUC_UNUSED) typedef struct _qemuNamespaceMknodItem qemuNamespaceMknodItem; typedef qemuNamespaceMknodItem *qemuNamespaceMknodItemPtr; struct _qemuNamespaceMknodItem { - const char *file; + char *file; char *target; bool bindmounted; GStatBuf sb; @@ -892,6 +892,7 @@ struct _qemuNamespaceMknodData { static void qemuNamespaceMknodItemClear(qemuNamespaceMknodItemPtr item) { + VIR_FREE(item->file); VIR_FREE(item->target); virFileFreeACLs(&item->acl); #ifdef WITH_SELINUX @@ -900,6 +901,8 @@ qemuNamespaceMknodItemClear(qemuNamespaceMknodItemPtr item) } +G_DEFINE_AUTO_CLEANUP_CLEAR_FUNC(qemuNamespaceMknodItem, qemuNamespaceMknodItemClear); + static void qemuNamespaceMknodDataClear(qemuNamespaceMknodDataPtr data) { @@ -1091,7 +1094,7 @@ qemuNamespaceMknodItemInit(qemuNamespaceMknodItemPtr item, bool isLink; bool needsBindMount; - item->file = file; + item->file = g_strdup(file); if (g_lstat(file, &item->sb) < 0) { if (errno == ENOENT) @@ -1166,11 +1169,13 @@ qemuNamespacePrepareOneItem(qemuNamespaceMknodDataPtr data, size_t ndevMountsPath) { long ttl = sysconf(_SC_SYMLOOP_MAX); - const char *next = file; + g_autofree char *next = g_strdup(file); size_t i; while (1) { - qemuNamespaceMknodItem item = { 0 }; + g_auto(qemuNamespaceMknodItem) item = { 0 }; + bool isLink; + bool addToData = false; int rc; rc = qemuNamespaceMknodItemInit(&item, cfg, vm, next); @@ -1182,6 +1187,8 @@ qemuNamespacePrepareOneItem(qemuNamespaceMknodDataPtr data, return -1; } + isLink = S_ISLNK(item.sb.st_mode); + if (STRPREFIX(next, QEMU_DEVPREFIX)) { for (i = 0; i < ndevMountsPath; i++) { if (STREQ(devMountsPath[i], "/dev")) @@ -1190,12 +1197,18 @@ qemuNamespacePrepareOneItem(qemuNamespaceMknodDataPtr data, break; } - if (i == ndevMountsPath && - VIR_APPEND_ELEMENT_COPY(data->items, data->nitems, item) < 0) - return -1; + if (i == ndevMountsPath) + addToData = true; } - if (!S_ISLNK(item.sb.st_mode)) + g_free(next); + next = g_strdup(item.target); + + if (addToData && + VIR_APPEND_ELEMENT(data->items, data->nitems, item) < 0) + return -1; + + if (!isLink) break; if (ttl-- == 0) { @@ -1204,8 +1217,6 @@ qemuNamespacePrepareOneItem(qemuNamespaceMknodDataPtr data, next); return -1; } - - next = item.target; } return 0; -- 2.26.2

2 1

[PATCH] qemu: Allow setting affinity to fail and don't report error
by Martin Kletzander 07 Sep '20

07 Sep '20

This is just a clean-up of commit 3791f29b085c using the new parameter of virProcessSetAffinity() introduced in commit 9514e24984ee so that there is no error reported in the logs. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- src/qemu/qemu_process.c | 65 +++++++++++++++++++---------------------- 1 file changed, 30 insertions(+), 35 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 04e5cbb65969..e29f35e10576 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -2569,24 +2569,21 @@ qemuProcessInitCpuAffinity(virDomainObjPtr vm) return -1; } + /* + * We only want to error out if we failed to set the affinity to + * user-requested mapping. If we are just trying to reset the affinity + * to all CPUs and this fails it can only be an issue if: + * 1) libvirtd does not have CAP_SYS_NICE + * 2) libvirtd does not run on all CPUs + * + * This scenario can easily occurr when libvirtd is run inside a + * container with restrictive permissions and CPU pinning. + * + * See also: https://bugzilla.redhat.com/1819801#c2 + */ if (cpumapToSet && - virProcessSetAffinity(vm->pid, cpumapToSet, false) < 0) { - /* - * We only want to error out if we failed to set the affinity to - * user-requested mapping. If we are just trying to reset the affinity - * to all CPUs and this fails it can only be an issue if: - * 1) libvirtd does not have CAP_SYS_NICE - * 2) libvirtd does not run on all CPUs - * - * This scenario can easily occurr when libvirtd is run inside a - * container with restrictive permissions and CPU pinning. - * - * See also: https://bugzilla.redhat.com/1819801#c2 - */ - if (settingAll) - virResetLastError(); - else - return -1; + virProcessSetAffinity(vm->pid, cpumapToSet, settingAll) < 0) { + return -1; } return 0; @@ -2739,25 +2736,23 @@ qemuProcessSetupPid(virDomainObjPtr vm, if (!affinity_cpumask) affinity_cpumask = use_cpumask; - /* Setup legacy affinity. */ + /* Setup legacy affinity. + * + * We only want to error out if we failed to set the affinity to + * user-requested mapping. If we are just trying to reset the affinity + * to all CPUs and this fails it can only be an issue if: + * 1) libvirtd does not have CAP_SYS_NICE + * 2) libvirtd does not run on all CPUs + * + * This scenario can easily occurr when libvirtd is run inside a + * container with restrictive permissions and CPU pinning. + * + * See also: https://bugzilla.redhat.com/1819801#c2 + */ if (affinity_cpumask && - virProcessSetAffinity(pid, affinity_cpumask, false) < 0) { - /* - * We only want to error out if we failed to set the affinity to - * user-requested mapping. If we are just trying to reset the affinity - * to all CPUs and this fails it can only be an issue if: - * 1) libvirtd does not have CAP_SYS_NICE - * 2) libvirtd does not run on all CPUs - * - * This scenario can easily occurr when libvirtd is run inside a - * container with restrictive permissions and CPU pinning. - * - * See also: https://bugzilla.redhat.com/1819801#c2 - */ - if (affinity_cpumask == hostcpumap) - virResetLastError(); - else - goto cleanup; + virProcessSetAffinity(pid, affinity_cpumask, + affinity_cpumask == hostcpumap) < 0) { + goto cleanup; } /* Set scheduler type and priority, but not for the main thread. */ -- 2.28.0

2 1

[PATCH] Do not report error when setting affinity is allowed to fail
by Martin Kletzander 07 Sep '20

07 Sep '20

Suggested-by: Ján Tomko <jtomko(a)redhat.com> Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- src/lxc/lxc_controller.c | 2 +- src/qemu/qemu_driver.c | 7 ++++--- src/qemu/qemu_process.c | 10 +++++----- src/util/virprocess.c | 32 +++++++++++++++++++++++--------- src/util/virprocess.h | 2 +- 5 files changed, 34 insertions(+), 19 deletions(-) diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c index 0a496fb7886c..37a28ac2f3c1 100644 --- a/src/lxc/lxc_controller.c +++ b/src/lxc/lxc_controller.c @@ -775,7 +775,7 @@ static int virLXCControllerSetupCpuAffinity(virLXCControllerPtr ctrl) * so use '0' to indicate our own process ID. No threads are * running at this point */ - if (virProcessSetAffinity(0 /* Self */, cpumapToSet) < 0) { + if (virProcessSetAffinity(0 /* Self */, cpumapToSet, false) < 0) { virBitmapFree(cpumap); return -1; } diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index ce72e1021d16..a792a1283253 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -4529,7 +4529,8 @@ qemuDomainPinVcpuLive(virDomainObjPtr vm, goto cleanup; } - if (virProcessSetAffinity(qemuDomainGetVcpuPid(vm, vcpu), cpumap) < 0) + if (virProcessSetAffinity(qemuDomainGetVcpuPid(vm, vcpu), + cpumap, false) < 0) goto cleanup; } @@ -4747,7 +4748,7 @@ qemuDomainPinEmulator(virDomainPtr dom, } } - if (virProcessSetAffinity(vm->pid, pcpumap) < 0) + if (virProcessSetAffinity(vm->pid, pcpumap, false) < 0) goto endjob; virBitmapFree(def->cputune.emulatorpin); @@ -5222,7 +5223,7 @@ qemuDomainPinIOThread(virDomainPtr dom, } } - if (virProcessSetAffinity(iothrid->thread_id, pcpumap) < 0) + if (virProcessSetAffinity(iothrid->thread_id, pcpumap, false) < 0) goto endjob; if (virDomainObjSave(vm, driver->xmlopt, cfg->stateDir) < 0) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 17d083d192a5..423c60c7c85b 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -2573,7 +2573,7 @@ qemuProcessInitCpuAffinity(virDomainObjPtr vm) } if (cpumapToSet && - virProcessSetAffinity(vm->pid, cpumapToSet) < 0) { + virProcessSetAffinity(vm->pid, cpumapToSet, false) < 0) { /* * We only want to error out if we failed to set the affinity to * user-requested mapping. If we are just trying to reset the affinity @@ -2743,7 +2743,8 @@ qemuProcessSetupPid(virDomainObjPtr vm, affinity_cpumask = use_cpumask; /* Setup legacy affinity. */ - if (affinity_cpumask && virProcessSetAffinity(pid, affinity_cpumask) < 0) { + if (affinity_cpumask && + virProcessSetAffinity(pid, affinity_cpumask, false) < 0) { /* * We only want to error out if we failed to set the affinity to * user-requested mapping. If we are just trying to reset the affinity @@ -2751,9 +2752,8 @@ qemuProcessSetupPid(virDomainObjPtr vm, * 1) libvirtd does not have CAP_SYS_NICE * 2) libvirtd does not run on all CPUs * - * However since this scenario is very improbable, we rather skip - * reporting the error because it helps running libvirtd in a a scenario - * where pinning is handled by someone else. + * This scenario can easily occurr when libvirtd is run inside a + * container with restrictive permissions and CPU pinning. * * See also: https://bugzilla.redhat.com/1819801#c2 */ diff --git a/src/util/virprocess.c b/src/util/virprocess.c index 9de356505104..e9df56389621 100644 --- a/src/util/virprocess.c +++ b/src/util/virprocess.c @@ -441,7 +441,7 @@ int virProcessKillPainfully(pid_t pid, bool force) #if WITH_SCHED_GETAFFINITY -int virProcessSetAffinity(pid_t pid, virBitmapPtr map) +int virProcessSetAffinity(pid_t pid, virBitmapPtr map, bool quiet) { size_t i; int numcpus = 1024; @@ -479,9 +479,14 @@ int virProcessSetAffinity(pid_t pid, virBitmapPtr map) numcpus = numcpus << 2; goto realloc; } - virReportSystemError(errno, - _("cannot set CPU affinity on process %d"), pid); - return -1; + if (quiet) { + VIR_DEBUG("cannot set CPU affinity on process %d: %s", + pid, g_strerror(errno)); + } else { + virReportSystemError(errno, + _("cannot set CPU affinity on process %d"), pid); + return -1; + } } CPU_FREE(mask); @@ -533,7 +538,8 @@ virProcessGetAffinity(pid_t pid) #elif defined(WITH_BSD_CPU_AFFINITY) int virProcessSetAffinity(pid_t pid, - virBitmapPtr map) + virBitmapPtr map, + bool quiet) { size_t i; cpuset_t mask; @@ -546,9 +552,14 @@ int virProcessSetAffinity(pid_t pid, if (cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID, pid, sizeof(mask), &mask) != 0) { - virReportSystemError(errno, - _("cannot set CPU affinity on process %d"), pid); - return -1; + if (quiet) { + VIR_DEBUG("cannot set CPU affinity on process %d: %s", + pid, g_strerror(errno)); + } else { + virReportSystemError(errno, + _("cannot set CPU affinity on process %d"), pid); + return -1; + } } return 0; @@ -582,8 +593,11 @@ virProcessGetAffinity(pid_t pid) #else /* WITH_SCHED_GETAFFINITY */ int virProcessSetAffinity(pid_t pid G_GNUC_UNUSED, - virBitmapPtr map G_GNUC_UNUSED) + virBitmapPtr map G_GNUC_UNUSED, + bool quiet G_GNUC_UNUSED) { + /* The @quiet parameter is ignored here, it is used only for silencing + * actual failures. */ virReportSystemError(ENOSYS, "%s", _("Process CPU affinity is not supported on this platform")); return -1; diff --git a/src/util/virprocess.h b/src/util/virprocess.h index 437deb18305b..34210d6c9d62 100644 --- a/src/util/virprocess.h +++ b/src/util/virprocess.h @@ -58,7 +58,7 @@ int virProcessKillPainfullyDelay(pid_t pid, bool force, unsigned int extradelay); -int virProcessSetAffinity(pid_t pid, virBitmapPtr map); +int virProcessSetAffinity(pid_t pid, virBitmapPtr map, bool quiet); virBitmapPtr virProcessGetAffinity(pid_t pid); -- 2.28.0

2 3