On 20.12.2017 16:52, Christian Borntraeger wrote:
> From: Michael Mueller <mimu@xxxxxxxxxxxxxxxxxx>
>
> It is not required to take to a lock to protect access to the cpuflags
> of the local interrupt structure of a vcpu as the performed operation
> is an atomic_or.
>
> Signed-off-by: Michael Mueller <mimu@xxxxxxxxxxxxxxxxxx>
> Reviewed-by: Christian Borntraeger <borntraeger@xxxxxxxxxx>
> Signed-off-by: Christian Borntraeger <borntraeger@xxxxxxxxxx>
> ---
> arch/s390/kvm/interrupt.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
> index 024ad8bcc516..818aa4248b0f 100644
> --- a/arch/s390/kvm/interrupt.c
> +++ b/arch/s390/kvm/interrupt.c
> @@ -1569,7 +1569,6 @@ static void __floating_irq_kick(struct kvm *kvm, u64 type)
>
> /* make the VCPU drop out of the SIE, or wake it up if sleeping */
> li = &dst_vcpu->arch.local_int;
> - spin_lock(&li->lock);
> switch (type) {
> case KVM_S390_MCHK:
> atomic_or(CPUSTAT_STOP_INT, li->cpuflags);
> @@ -1581,7 +1580,6 @@ static void __floating_irq_kick(struct kvm *kvm, u64 type)
> atomic_or(CPUSTAT_EXT_INT, li->cpuflags);
> break;
> }
> - spin_unlock(&li->lock);
> kvm_s390_vcpu_wakeup(dst_vcpu);
> }
>
>
I remember that being somehow used to avoid the target VCPU just
clearing the indicators via __reset_intercept_indicators().
But as far as I can see, this has no effect and
set_intercept_indicators() will take care of it. In the worst case, we
have too many flags set, simply resulting in a VCPU exit and the
superfluous flags getting cleared.
So this looks sane to me.
--
Thanks,
David / dhildenb
