From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: rkrcmar@redhat.com, christoffer.dall@linaro.org,
marc.zyngier@arm.com, james.hogan@imgtec.com, paulus@samba.org,
cornelia.huck@de.ibm.com, kvmarm@lists.cs.columbia.edu,
kvm-ppc@vger.kernel.org
Subject: Re: [PATCH] KVM: race-free exit from KVM_RUN without POSIX signals
Date: Wed, 15 Feb 2017 16:24:12 +0100 [thread overview]
Message-ID: <2f9cd5cd-1bb5-0d9e-cb84-26615b211523@de.ibm.com> (raw)
In-Reply-To: <1487169821-14806-1-git-send-email-pbonzini@redhat.com>
On 02/15/2017 03:43 PM, Paolo Bonzini wrote:
> The purpose of the KVM_SET_SIGNAL_MASK API is to let userspace "kick"
> a VCPU out of KVM_RUN through a POSIX signal. A signal is attached
> to a dummy signal handler; by blocking the signal outside KVM_RUN and
> unblocking it inside, this possible race is closed:
>
> VCPU thread service thread
> --------------------------------------------------------------
> check flag
> set flag
> raise signal
> (signal handler does nothing)
> KVM_RUN
>
> However, one issue with KVM_SET_SIGNAL_MASK is that it has to take
> tsk->sighand->siglock on every KVM_RUN. This lock is often on a
> remote NUMA node, because it is on the node of a thread's creator.
> Taking this lock can be very expensive if there are many userspace
> exits (as is the case for SMP Windows VMs without Hyper-V reference
> time counter).
>
> As an alternative, we can put the flag directly in kvm_run so that
> KVM can see it:
>
> VCPU thread service thread
> --------------------------------------------------------------
> raise signal
> signal handler
> set run->immediate_exit
> KVM_RUN
> check run->immediate_exit
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Generic parts, the concept and the s390 parts looks good. (not tested yet, though)
WARNING: multiple messages have this Message-ID (diff)
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: james.hogan@imgtec.com, marc.zyngier@arm.com,
kvm-ppc@vger.kernel.org, paulus@samba.org,
cornelia.huck@de.ibm.com, kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH] KVM: race-free exit from KVM_RUN without POSIX signals
Date: Wed, 15 Feb 2017 16:24:12 +0100 [thread overview]
Message-ID: <2f9cd5cd-1bb5-0d9e-cb84-26615b211523@de.ibm.com> (raw)
In-Reply-To: <1487169821-14806-1-git-send-email-pbonzini@redhat.com>
On 02/15/2017 03:43 PM, Paolo Bonzini wrote:
> The purpose of the KVM_SET_SIGNAL_MASK API is to let userspace "kick"
> a VCPU out of KVM_RUN through a POSIX signal. A signal is attached
> to a dummy signal handler; by blocking the signal outside KVM_RUN and
> unblocking it inside, this possible race is closed:
>
> VCPU thread service thread
> --------------------------------------------------------------
> check flag
> set flag
> raise signal
> (signal handler does nothing)
> KVM_RUN
>
> However, one issue with KVM_SET_SIGNAL_MASK is that it has to take
> tsk->sighand->siglock on every KVM_RUN. This lock is often on a
> remote NUMA node, because it is on the node of a thread's creator.
> Taking this lock can be very expensive if there are many userspace
> exits (as is the case for SMP Windows VMs without Hyper-V reference
> time counter).
>
> As an alternative, we can put the flag directly in kvm_run so that
> KVM can see it:
>
> VCPU thread service thread
> --------------------------------------------------------------
> raise signal
> signal handler
> set run->immediate_exit
> KVM_RUN
> check run->immediate_exit
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Generic parts, the concept and the s390 parts looks good. (not tested yet, though)
WARNING: multiple messages have this Message-ID (diff)
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: rkrcmar@redhat.com, christoffer.dall@linaro.org,
marc.zyngier@arm.com, james.hogan@imgtec.com, paulus@samba.org,
cornelia.huck@de.ibm.com, kvmarm@lists.cs.columbia.edu,
kvm-ppc@vger.kernel.org
Subject: Re: [PATCH] KVM: race-free exit from KVM_RUN without POSIX signals
Date: Wed, 15 Feb 2017 15:24:12 +0000 [thread overview]
Message-ID: <2f9cd5cd-1bb5-0d9e-cb84-26615b211523@de.ibm.com> (raw)
In-Reply-To: <1487169821-14806-1-git-send-email-pbonzini@redhat.com>
On 02/15/2017 03:43 PM, Paolo Bonzini wrote:
> The purpose of the KVM_SET_SIGNAL_MASK API is to let userspace "kick"
> a VCPU out of KVM_RUN through a POSIX signal. A signal is attached
> to a dummy signal handler; by blocking the signal outside KVM_RUN and
> unblocking it inside, this possible race is closed:
>
> VCPU thread service thread
> --------------------------------------------------------------
> check flag
> set flag
> raise signal
> (signal handler does nothing)
> KVM_RUN
>
> However, one issue with KVM_SET_SIGNAL_MASK is that it has to take
> tsk->sighand->siglock on every KVM_RUN. This lock is often on a
> remote NUMA node, because it is on the node of a thread's creator.
> Taking this lock can be very expensive if there are many userspace
> exits (as is the case for SMP Windows VMs without Hyper-V reference
> time counter).
>
> As an alternative, we can put the flag directly in kvm_run so that
> KVM can see it:
>
> VCPU thread service thread
> --------------------------------------------------------------
> raise signal
> signal handler
> set run->immediate_exit
> KVM_RUN
> check run->immediate_exit
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Generic parts, the concept and the s390 parts looks good. (not tested yet, though)
next prev parent reply other threads:[~2017-02-15 15:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-15 14:43 [PATCH] KVM: race-free exit from KVM_RUN without POSIX signals Paolo Bonzini
2017-02-15 14:43 ` Paolo Bonzini
2017-02-15 14:43 ` Paolo Bonzini
2017-02-15 15:24 ` Christian Borntraeger [this message]
2017-02-15 15:24 ` Christian Borntraeger
2017-02-15 15:24 ` Christian Borntraeger
2017-02-15 15:56 ` Paolo Bonzini
2017-02-15 15:56 ` Paolo Bonzini
2017-02-16 16:19 ` Radim Krčmář
2017-02-16 16:19 ` Radim Krčmář
2017-02-16 19:26 ` David Hildenbrand
2017-02-16 19:26 ` David Hildenbrand
2017-02-16 19:26 ` David Hildenbrand
2017-02-17 9:40 ` Paolo Bonzini
2017-02-17 9:40 ` Paolo Bonzini
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=2f9cd5cd-1bb5-0d9e-cb84-26615b211523@de.ibm.com \
--to=borntraeger@de.ibm.com \
--cc=christoffer.dall@linaro.org \
--cc=cornelia.huck@de.ibm.com \
--cc=james.hogan@imgtec.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=paulus@samba.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.