But note that due to dynamic library loading this example will not work
before we actually make use of thread_context_create_thread() in QEMU
code, because the type will otherwise not get registered.
What do you mean exactly by "not work"? It's not "CLI option or HMP
command fails":
For me, if I compile patch #1-#3 only, I get:
$ ./build/qemu-system-x86_64 -S -display none -nodefaults -monitor stdio
-object thread-context,id=tc1,cpu-affinity=0-1,cpu-affinity=6-7
qemu-system-x86_64: invalid object type: thread-context
Reason is that, without a call to thread_context_create_thread(), we
won't trigger type_init(thread_context_register_types) and consequently,
the type won't be registered.
Is it really different in your environment? Maybe it depends on the QEMU
config?
$ upstream-qemu -S -display none -nodefaults -monitor stdio -object
thread-context,id=tc1,cpu-affinity=0-1,cpu-affinity=6-7
QEMU 7.1.50 monitor - type 'help' for more information
(qemu) qom-get tc1 cpu-affinity
[
0,
1,
6,
7
]
(qemu) info cpus
* CPU #0: thread_id=1670613
Even though the affinities refer to nonexistent CPUs :)
CPU affinities are CPU numbers on your system (host), not QEMU vCPU
numbers. I could talk about physical CPU numbers in the doc here,
although I am not sure if that really helps. What about "host CPU
numbers" and in patch #4 "host node numbers"?
Seems to match what we document for @MemoryBackendProperties:
"@host-nodes: the list of NUMA host nodes to bind the memory to"
But unrelated to that, pthread_setaffinity_np() won't bail out on CPUs
that are currently not available in the host -- because one might
online/hotplug them later. It only bails out if none of the CPUs is
currently available in the host:
https://man7.org/linux/man-pages/man3/pthread_setaffinity_np.3.html
EINVAL (pthread_setaffinity_np()) The affinity bit mask mask
contains no processors that are currently physically on
the system and permitted to the thread according to any
restrictions that may be imposed by the "cpuset" mechanism
described in cpuset(7).
It will bail out on CPUs that cannot be available in the host though,
because it's impossible due to the kernel config:
EINVAL (pthread_setaffinity_np()) cpuset specified a CPU that was
outside the set supported by the kernel. (The kernel
configuration option CONFIG_NR_CPUS defines the range of
the set supported by the kernel data type used to
represent CPU sets.)
A ThreadContext can be reused, simply by reconfiguring the CPU affinity.
So, when a thread is created, its affinity comes from its thread context
(if any). When I later change the context's affinity, it does *not*
affect existing threads, only future ones. Correct?
Yes, that's the current state.
Reviewed-by: Michal Privoznik <mpriv...@redhat.com>
Signed-off-by: David Hildenbrand <da...@redhat.com>
---
include/qemu/thread-context.h | 57 +++++++
qapi/qom.json | 17 +++
util/meson.build | 1 +
util/oslib-posix.c | 1 +
util/thread-context.c | 278 ++++++++++++++++++++++++++++++++++
5 files changed, 354 insertions(+)
create mode 100644 include/qemu/thread-context.h
create mode 100644 util/thread-context.c
diff --git a/include/qemu/thread-context.h b/include/qemu/thread-context.h
new file mode 100644
index 0000000000..2ebd6b7fe1
--- /dev/null
+++ b/include/qemu/thread-context.h
@@ -0,0 +1,57 @@
+/*
+ * QEMU Thread Context
+ *
+ * Copyright Red Hat Inc., 2022
+ *
+ * Authors:
+ * David Hildenbrand <da...@redhat.com>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#ifndef SYSEMU_THREAD_CONTEXT_H
+#define SYSEMU_THREAD_CONTEXT_H
+
+#include "qapi/qapi-types-machine.h"
+#include "qemu/thread.h"
+#include "qom/object.h"
+
+#define TYPE_THREAD_CONTEXT "thread-context"
+OBJECT_DECLARE_TYPE(ThreadContext, ThreadContextClass,
+ THREAD_CONTEXT)
+
+struct ThreadContextClass {
+ ObjectClass parent_class;
+};
+
+struct ThreadContext {
+ /* private */
+ Object parent;
+
+ /* private */
+ unsigned int thread_id;
+ QemuThread thread;
+
+ /* Semaphore to wait for context thread action. */
+ QemuSemaphore sem;
+ /* Semaphore to wait for action in context thread. */
+ QemuSemaphore sem_thread;
+ /* Mutex to synchronize requests. */
+ QemuMutex mutex;
+
+ /* Commands for the thread to execute. */
+ int thread_cmd;
+ void *thread_cmd_data;
+
+ /* CPU affinity bitmap used for initialization. */
+ unsigned long *init_cpu_bitmap;
+ int init_cpu_nbits;
+};
+
+void thread_context_create_thread(ThreadContext *tc, QemuThread *thread,
+ const char *name,
+ void *(*start_routine)(void *), void *arg,
+ int mode);
+
+#endif /* SYSEMU_THREAD_CONTEXT_H */
diff --git a/qapi/qom.json b/qapi/qom.json
index 80dd419b39..67d47f4051 100644
--- a/qapi/qom.json
+++ b/qapi/qom.json
@@ -830,6 +830,21 @@
'reduced-phys-bits': 'uint32',
'*kernel-hashes': 'bool' } }
+##
+# @ThreadContextProperties:
+#
+# Properties for thread context objects.
+#
+# @cpu-affinity: the list of CPU numbers used as CPU affinity for all threads
+# created in the thread context (default: QEMU main thread
+# affinity)
Another ignorant question: is the QEMU main thread affinity fixed or
configurable? If configurable, how?
AFAIK, it's only configurable externally, for example, via "virsh
emulatorpin". There is no QEMU interface to adjust that (because it
wouldn't work).
Libvirt will essentially trigger "taskset" on the emulator thread to
change its CPU affinity.
--
Thanks,
David / dhildenb
