[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c8294b01-62d1-95df-6ff6-213f945a434f@redhat.com>
Date: Fri, 2 Aug 2019 23:35:36 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Thomas Gleixner <tglx@...utronix.de>,
Sean Christopherson <sean.j.christopherson@...el.com>
Cc: Oleg Nesterov <oleg@...hat.com>,
LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
Sebastian Siewior <bigeasy@...utronix.de>,
Anna-Maria Gleixner <anna-maria@...utronix.de>,
Steven Rostedt <rostedt@...dmis.org>,
Julia Cartwright <julia@...com>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>,
Frederic Weisbecker <fweisbec@...il.com>, kvm@...r.kernel.org,
Radim Krcmar <rkrcmar@...hat.com>,
John Stultz <john.stultz@...aro.org>,
Andy Lutomirski <luto@...nel.org>,
"Paul E. McKenney" <paulmck@...ux.ibm.com>
Subject: Re: [patch 2/5] x86/kvm: Handle task_work on VMENTER/EXIT
On 01/08/19 23:47, Thomas Gleixner wrote:
> Right you are about cond_resched() being called, but for SRCU this does not
> matter unless there is some way to do a synchronize operation on that SRCU
> entity. It might have some other performance side effect though.
I would use srcu_read_unlock/lock around the call.
However, I'm wondering if the API can be improved because basically we
have six functions for three checks of TIF flags. Does it make sense to
have something like task_has_request_flags and task_do_requests (names
are horrible I know) that can be used like
if (task_has_request_flags()) {
int err;
...srcu_read_unlock...
// return -EINTR if signal_pending
err = task_do_requests();
if (err < 0)
goto exit_no_srcu_read_unlock;
...srcu_read_lock...
}
taking care of all three cases with a single hook? This is important
especially because all these checks are done by all KVM architectures in
slightly different ways, and a unified API would be a good reason to
make all architectures look the same.
(Of course I could also define this unified API in virt/kvm/kvm_main.c,
so this is not blocking the series in any way!).
Paolo
Powered by blists - more mailing lists