Re: [PATCH v2 3/7] util: Introduce ThreadContext user-creatable object

[David Hildenbrand <david@redhat.com>]

>> 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 <mprivozn@redhat.com>
>> Signed-off-by: David Hildenbrand <david@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 <david@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