Thanks!
I'm adding
"Note that the CPU affinity of previously created threads will not get
adjusted."
and
"In general, the interface behaves like pthread_setaffinity_np(): host CPU
numbers that are currently not available are ignored; only host CPU
numbers that are impossible with the
David Hildenbrand writes:
> Thanks Markus!
>
>> I just tested again, and get the same result as you. I figure my
>> previous test was with the complete series.
>> PATCH 5 appears to make it work. Suggest to say something like "The
>> commit after next will make this work".
>
> I'll phrase it
Thanks Markus!
I just tested again, and get the same result as you. I figure my
previous test was with the complete series.
PATCH 5 appears to make it work. Suggest to say something like "The
commit after next will make this work".
I'll phrase it like " We'll wire this up next to make it
David Hildenbrand writes:
>>> 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
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,
David Hildenbrand writes:
> Setting the CPU affinity of QEMU threads is a bit problematic, because
> QEMU doesn't always have permissions to set the CPU affinity itself,
> for example, with seccomp after initialized by QEMU:
> -sandbox enable=on,resourcecontrol=deny
>
> General information
Setting the CPU affinity of QEMU threads is a bit problematic, because
QEMU doesn't always have permissions to set the CPU affinity itself,
for example, with seccomp after initialized by QEMU:
-sandbox enable=on,resourcecontrol=deny
General information about CPU affinities can be found in the
