From: Andy Lutomirski <luto@amacapital.net>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <sean.j.christopherson@intel.com>,
Oleg Nesterov <oleg@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
x86@kernel.org, Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Sebastian Siewior <bigeasy@linutronix.de>,
Anna-Maria Gleixner <anna-maria@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>,
Julia Cartwright <julia@ni.com>,
Paul McKenney <paulmck@linux.vnet.ibm.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
kvm@vger.kernel.org, Radim Krcmar <rkrcmar@redhat.com>,
John Stultz <john.stultz@linaro.org>,
Andy Lutomirski <luto@kernel.org>,
"Paul E. McKenney" <paulmck@linux.ibm.com>
Subject: Re: [patch 2/5] x86/kvm: Handle task_work on VMENTER/EXIT
Date: Fri, 2 Aug 2019 15:39:22 -0700 [thread overview]
Message-ID: <89E42BCC-47A8-458B-B06A-D6A20D20512C@amacapital.net> (raw)
In-Reply-To: <alpine.DEB.2.21.1908030015330.4029@nanos.tec.linutronix.de>
> On Aug 2, 2019, at 3:22 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
>
>> On Fri, 2 Aug 2019, Paolo Bonzini wrote:
>>> 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!).
>
> You're not holding up something. Having a common function for this is
> definitely the right approach.
>
> As this is virt specific because it only checks for non arch specific bits
> (TIF_NOTIFY_RESUME should be available for all KVM archs) and the TIF bits
> are a subset of the available TIF bits because all others do not make any
> sense there, this really should be a common function for KVM so that all
> other archs which obviously lack a TIF_NOTIFY_RESUME check, can be fixed up
> and consolidated. If we add another TIF check later then we only have to do
> it in one place.
>
>
If we add a real API for this, can we make it, or a very similar API, work for exit_to_usermode_loop() too? Maybe:
bool usermode_work_pending();
bool guestmode_work_pending();
void do_usermode_work();
void do_guestmode_work();
The first two are called with IRQs off. The latter two are called with IRQs on.
next prev parent reply other threads:[~2019-08-02 22:39 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-01 14:32 [patch 0/5] posix-cpu-timers: Move expiry into task work context Thomas Gleixner
2019-08-01 14:32 ` [patch 1/5] tracehook: Provide TIF_NOTIFY_RESUME handling for KVM Thomas Gleixner
2019-08-01 14:48 ` Peter Zijlstra
2019-08-01 15:10 ` Thomas Gleixner
2019-08-01 17:02 ` Andy Lutomirski
2019-08-01 14:32 ` [patch 2/5] x86/kvm: Handle task_work on VMENTER/EXIT Thomas Gleixner
2019-08-01 16:24 ` Oleg Nesterov
2019-08-01 18:34 ` Thomas Gleixner
2019-08-01 21:35 ` Sean Christopherson
2019-08-01 21:44 ` Peter Zijlstra
2019-08-01 21:44 ` Thomas Gleixner
2019-08-01 21:47 ` Thomas Gleixner
2019-08-02 21:35 ` Paolo Bonzini
2019-08-02 22:22 ` Thomas Gleixner
2019-08-02 22:39 ` Andy Lutomirski [this message]
2019-08-02 12:04 ` Oleg Nesterov
2019-08-01 14:32 ` [patch 3/5] posix-cpu-timers: Split run_posix_cpu_timers() Thomas Gleixner
2019-08-01 14:32 ` [patch 4/5] posix-cpu-timers: Defer timer handling to task_work Thomas Gleixner
2019-08-01 14:51 ` Peter Zijlstra
2019-08-01 15:10 ` Thomas Gleixner
2019-08-01 15:39 ` Oleg Nesterov
2019-08-01 18:41 ` Thomas Gleixner
2019-08-01 14:32 ` [patch 5/5] x86: Select POSIX_CPU_TIMERS_TASK_WORK Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=89E42BCC-47A8-458B-B06A-D6A20D20512C@amacapital.net \
--to=luto@amacapital.net \
--cc=anna-maria@linutronix.de \
--cc=bigeasy@linutronix.de \
--cc=fweisbec@gmail.com \
--cc=john.stultz@linaro.org \
--cc=julia@ni.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=paulmck@linux.ibm.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rkrcmar@redhat.com \
--cc=rostedt@goodmis.org \
--cc=sean.j.christopherson@intel.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).