On Fri, 12 Aug 2022 at 08:59, Stefan Weil via wrote:
>
> Signed-off-by: Stefan Weil
> ---
> docs/about/deprecated.rst | 2 +-
> docs/specs/acpi_erst.rst| 4 ++--
> docs/system/devices/canokey.rst | 8
> docs/system/devices/cxl.rst | 12 ++--
> 4 files
On Fri, 12 Aug 2022 at 08:59, Stefan Weil via wrote:
>
> Signed-off-by: Stefan Weil
> ---
Reviewed-by: Peter Maydell
thanks
-- PMM
Since its 5.14 release the Linux kernel allows userspace to
define trusted groups of processes/threads that can run on
sibling Hyper Threads (HT) at the same time. This is to mitigate
side channel attacks like L1TF or MDS. If there are no tasks to
fully utilize all HTs, then a HT will idle instead
For QEMU_SCHED_CORE_VCPUS case, the vCPU threads should be placed
all into one scheduling group, but not the emulator or any of its
threads. Therefore, as soon as vCPU TIDs are detected, fork off a
child which then creates a separate scheduling group and adds all
vCPU threads into it.
Please
As advertised in the previous commit, QEMU_SCHED_CORE_VCPUS case
is implemented for hotplug case. The implementation is very
similar to the cold boot case, except here we fork off for every
vCPU (because the implementation is done in
qemuProcessSetupVcpu() which is also the function that's called
For QEMU_SCHED_CORE_FULL case, all helper processes should be
placed into the same scheduling group as the QEMU process they
serve. It may happen though, that a helper process is started
before QEMU (cold start of a domain). But we have the dummy
process running from which the QEMU process will
For QEMU_SCHED_CORE_EMULATOR or QEMU_SCHED_CORE_FULL the QEMU
process (and its vCPU threads) should be placed into its own
scheduling group. Since we have the dummy process running for
exactly this purpose use its PID as an argument to
virCommandSetRunAmong().
Signed-off-by: Michal Privoznik
---
The aim of this helper function is to spawn a child process in
which new scheduling group is created. This dummy process will
then used to distribute scheduling group from (e.g. when starting
helper processes or QEMU itself). The process is not needed for
QEMU_SCHED_CORE_NONE case (obviously) nor
Ideally, we would just pick the best default and users wouldn't
have to intervene at all. But in some cases it may be handy to
not bother with SCHED_CORE at all or place helper processes into
the same group as QEMU. Introduce a knob in qemu.conf to allow
users control this behaviour.
There are two modes of core scheduling that are handy wrt
virCommand:
1) create new trusted group when executing a virCommand
2) place freshly executed virCommand into the trusted group of
another process.
Therefore, implement these two new operations as new APIs:
virCommandSetRunAlone() and
v3 of:
https://listman.redhat.com/archives/libvir-list/2022-June/232595.html
diff to v2:
- Instead of opting out, the feature is disabled by default. Until we
address CPU pinning (and other points I've raised in v2 cover letter)
users might face a performance problems if this was turned on
On 8/12/22 00:44, Jim Fehlig wrote:
> Inspired by Tim's patch to fix my earlier omission
>
> https://listman.redhat.com/archives/libvir-list/2022-August/233624.html
>
> Jim Fehlig (3):
> schema: Remove optional nesting in hostcpu rng
> schema: Don't enforce ordering of hostcpu capabilities
12 matches
Mail list logo
