linux-kernel - Re: [RFC PATCH v2 0/5] Paravirt Scheduling (Dynamic vcpu priority management)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240712122408.3f434cc5@rorschach.local.home>
Date: Fri, 12 Jul 2024 12:24:08 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Joel Fernandes <joel@...lfernandes.org>, Vineeth Remanan Pillai
 <vineeth@...byteword.org>, Sean Christopherson <seanjc@...gle.com>, Ben
 Segall <bsegall@...gle.com>, Borislav Petkov <bp@...en8.de>, Daniel Bristot
 de Oliveira <bristot@...hat.com>, Dave Hansen
 <dave.hansen@...ux.intel.com>, Dietmar Eggemann <dietmar.eggemann@....com>,
 "H . Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>, Juri
 Lelli <juri.lelli@...hat.com>, Mel Gorman <mgorman@...e.de>, Paolo Bonzini
 <pbonzini@...hat.com>, Andy Lutomirski <luto@...nel.org>, Peter Zijlstra
 <peterz@...radead.org>, Thomas Gleixner <tglx@...utronix.de>, Valentin
 Schneider <vschneid@...hat.com>, Vincent Guittot
 <vincent.guittot@...aro.org>, Vitaly Kuznetsov <vkuznets@...hat.com>,
 Wanpeng Li <wanpengli@...cent.com>, Suleiman Souhlal <suleiman@...gle.com>,
 Masami Hiramatsu <mhiramat@...nel.org>, himadrics@...ia.fr,
 kvm@...r.kernel.org, linux-kernel@...r.kernel.org, x86@...nel.org,
 graf@...zon.com, drjunior.org@...il.com
Subject: Re: [RFC PATCH v2 0/5] Paravirt Scheduling (Dynamic vcpu priority
 management)

On Fri, 12 Jul 2024 10:09:03 -0400
Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:

> > 
> > Steven Rostedt told me, what we instead need is a tracepoint callback in a
> > driver, that does the boosting.  
> 
> I utterly dislike changing the system behavior through tracepoints. They were
> designed to observe the system, not modify its behavior. If people start abusing
> them, then subsystem maintainers will stop adding them. Please don't do that.
> Add a notifier or think about integrating what you are planning to add into the
> driver instead.

I tend to agree that a notifier would be much better than using
tracepoints, but then I also think eBPF has already let that cat out of
the bag. :-p

All we need is a notifier that gets called at every VMEXIT.

The main issue that this is trying to solve is to boost the priority of
the guest without making the hypercall, so that it can quickly react
(lower the latency of reaction to an event). Now when the task is
unboosted, there's no avoiding of the hypercall as there's no other way
to tell the host that this vCPU should not be running at a higher
priority (the high priority may prevent schedules, or even checking the
new prio in the shared memory).

If there's a way to have a shared memory, via virtio or whatever, and
any notifier that gets called at any VMEXIT, then this is trivial to
implement.

-- Steve