[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1359d10f-1bee-e295-912d-8cdc5bf7a98c@redhat.com>
Date: Wed, 15 Feb 2017 16:56:42 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Christian Borntraeger <borntraeger@...ibm.com>,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Cc: james.hogan@...tec.com, marc.zyngier@....com,
kvm-ppc@...r.kernel.org, paulus@...ba.org,
cornelia.huck@...ibm.com, kvmarm@...ts.cs.columbia.edu
Subject: Re: [PATCH] KVM: race-free exit from KVM_RUN without POSIX signals
On 15/02/2017 16:24, Christian Borntraeger wrote:
> 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@...hat.com>
>
>
> Generic parts, the concept and the s390 parts looks good. (not tested yet, though)
Note that this series doesn't work (due to David's suggestion) with the
patches I posted last week.
Paolo
Powered by blists - more mailing lists