[PATCH 0/1] KVM: s390: backport for stable of "KVM: s390: index

[PATCH 0/1] KVM: s390: backport for stable of "KVM: s390: index

[Christian Borntraeger]

Stable team,

here is a backport for 4.19 of
commit a3e03bc1368 ("KVM: s390: index kvm->arch.idle_mask by vcpu_idx")
This basically removes the kick_mask parts that were introduced with
kernel 5.0 and fixes up the location of the idle_mask to the older
place.

FWIW, it might be a good idea to also backport
8750e72a79dd ("KVM: remember position in kvm->vcpus array") to avoid
a performance regression for large guests (many vCPUs) when this patch
is applied. 
@Paolo Bonzini, would you be ok with 8750e72a79dd in older stable releases?



Halil Pasic (1):
  KVM: s390: index kvm->arch.idle_mask by vcpu_idx

 arch/s390/kvm/interrupt.c | 4 ++--
 arch/s390/kvm/kvm-s390.h  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.31.1

[PATCH 1/1] KVM: s390: index kvm->arch.idle_mask by vcpu_idx

[Christian Borntraeger]

From: Halil Pasic <pasic@linux.ibm.com>

While in practice vcpu->vcpu_idx ==  vcpu->vcp_id is often true, it may
not always be, and we must not rely on this. Reason is that KVM decides
the vcpu_idx, userspace decides the vcpu_id, thus the two might not
match.

Currently kvm->arch.idle_mask is indexed by vcpu_id, which implies
that code like
for_each_set_bit(vcpu_id, kvm->arch.idle_mask, online_vcpus) {
                vcpu = kvm_get_vcpu(kvm, vcpu_id);
		do_stuff(vcpu);
}
is not legit. Reason is that kvm_get_vcpu expects an vcpu_idx, not an
vcpu_id.  The trouble is, we do actually use kvm->arch.idle_mask like
this. To fix this problem we have two options. Either use
kvm_get_vcpu_by_id(vcpu_id), which would loop to find the right vcpu_id,
or switch to indexing via vcpu_idx. The latter is preferable for obvious
reasons.

Let us make switch from indexing kvm->arch.idle_mask by vcpu_id to
indexing it by vcpu_idx.  To keep gisa_int.kicked_mask indexed by the
same index as idle_mask lets make the same change for it as well.

Fixes: 1ee0bc559dc3 ("KVM: s390: get rid of local_int array")
Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
Reviewed-by: Christian Bornträger <borntraeger@de.ibm.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: <stable@vger.kernel.org> # 3.15+
Link: https://lore.kernel.org/r/20210827125429.1912577-1-pasic@linux.ibm.com
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
[borntraeger@de.ibm.com]: change  idle mask, remove kicked_mask 
---
 arch/s390/kvm/interrupt.c | 4 ++--
 arch/s390/kvm/kvm-s390.h  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index 3515f2b55eb9..dc5ecaea30d7 100644
--- a/arch/s390/kvm/interrupt.c
+++ b/arch/s390/kvm/interrupt.c
@@ -318,13 +318,13 @@ static unsigned long deliverable_irqs(struct kvm_vcpu *vcpu)
 static void __set_cpu_idle(struct kvm_vcpu *vcpu)
 {
 	kvm_s390_set_cpuflags(vcpu, CPUSTAT_WAIT);
-	set_bit(vcpu->vcpu_id, vcpu->kvm->arch.float_int.idle_mask);
+	set_bit(kvm_vcpu_get_idx(vcpu), vcpu->kvm->arch.float_int.idle_mask);
 }
 
 static void __unset_cpu_idle(struct kvm_vcpu *vcpu)
 {
 	kvm_s390_clear_cpuflags(vcpu, CPUSTAT_WAIT);
-	clear_bit(vcpu->vcpu_id, vcpu->kvm->arch.float_int.idle_mask);
+	clear_bit(kvm_vcpu_get_idx(vcpu), vcpu->kvm->arch.float_int.idle_mask);
 }
 
 static void __reset_intercept_indicators(struct kvm_vcpu *vcpu)
diff --git a/arch/s390/kvm/kvm-s390.h b/arch/s390/kvm/kvm-s390.h
index 981e3ba97461..0a2ffd5378be 100644
--- a/arch/s390/kvm/kvm-s390.h
+++ b/arch/s390/kvm/kvm-s390.h
@@ -67,7 +67,7 @@ static inline int is_vcpu_stopped(struct kvm_vcpu *vcpu)
 
 static inline int is_vcpu_idle(struct kvm_vcpu *vcpu)
 {
-	return test_bit(vcpu->vcpu_id, vcpu->kvm->arch.float_int.idle_mask);
+	return test_bit(kvm_vcpu_get_idx(vcpu), vcpu->kvm->arch.float_int.idle_mask);
 }
 
 static inline int kvm_is_ucontrol(struct kvm *kvm)
-- 
2.31.1

Re: [PATCH 0/1] KVM: s390: backport for stable of "KVM: s390: index

[Greg KH]

On Mon, Sep 20, 2021 at 05:06:15PM +0200, Christian Borntraeger wrote:
> Stable team,
> 
> here is a backport for 4.19 of
> commit a3e03bc1368 ("KVM: s390: index kvm->arch.idle_mask by vcpu_idx")
> This basically removes the kick_mask parts that were introduced with
> kernel 5.0 and fixes up the location of the idle_mask to the older
> place.

Now queued up, thanks.

> FWIW, it might be a good idea to also backport
> 8750e72a79dd ("KVM: remember position in kvm->vcpus array") to avoid
> a performance regression for large guests (many vCPUs) when this patch
> is applied. 
> @Paolo Bonzini, would you be ok with 8750e72a79dd in older stable releases?

That would also have to go into 5.4.y, right?

thanks,

greg k-h

Re: [PATCH 0/1] KVM: s390: backport for stable of "KVM: s390: index

[Christian Borntraeger]

Am 20.09.21 um 17:24 schrieb Greg KH:
> On Mon, Sep 20, 2021 at 05:06:15PM +0200, Christian Borntraeger wrote:
>> Stable team,
>>
>> here is a backport for 4.19 of
>> commit a3e03bc1368 ("KVM: s390: index kvm->arch.idle_mask by vcpu_idx")
>> This basically removes the kick_mask parts that were introduced with
>> kernel 5.0 and fixes up the location of the idle_mask to the older
>> place.
> 
> Now queued up, thanks.
> 
>> FWIW, it might be a good idea to also backport
>> 8750e72a79dd ("KVM: remember position in kvm->vcpus array") to avoid
>> a performance regression for large guests (many vCPUs) when this patch
>> is applied.
>> @Paolo Bonzini, would you be ok with 8750e72a79dd in older stable releases?
> 
> That would also have to go into 5.4.y, right?
Ideally yes.

Re: [PATCH 0/1] KVM: s390: backport for stable of "KVM: s390: index

[Paolo Bonzini]

On 20/09/21 17:06, Christian Borntraeger wrote:
> here is a backport for 4.19 of
> commit a3e03bc1368 ("KVM: s390: index kvm->arch.idle_mask by vcpu_idx")
> This basically removes the kick_mask parts that were introduced with
> kernel 5.0 and fixes up the location of the idle_mask to the older
> place.
> 
> FWIW, it might be a good idea to also backport
> 8750e72a79dd ("KVM: remember position in kvm->vcpus array") to avoid
> a performance regression for large guests (many vCPUs) when this patch
> is applied.
> @Paolo Bonzini, would you be ok with 8750e72a79dd in older stable releases?

Sure, I suppose you're going to send a separate backport that I can ack.

Paolo

Re: [PATCH 1/1] KVM: s390: index kvm->arch.idle_mask by vcpu_idx

[Halil Pasic]

On Mon, 20 Sep 2021 17:06:16 +0200
Christian Borntraeger <borntraeger@de.ibm.com> wrote:

> Fixes: 1ee0bc559dc3 ("KVM: s390: get rid of local_int array")
> Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
> Reviewed-by: Christian Bornträger <borntraeger@de.ibm.com>
> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
> Cc: <stable@vger.kernel.org> # 3.15+
> Link: https://lore.kernel.org/r/20210827125429.1912577-1-pasic@linux.ibm.com
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> [borntraeger@de.ibm.com]: change  idle mask, remove kicked_mask 

LGTM. Thanks for taking care of this!

Re: [PATCH 0/1] KVM: s390: backport for stable of "KVM: s390: index

[Christian Borntraeger]

Am 20.09.21 um 20:05 schrieb Paolo Bonzini:
> On 20/09/21 17:06, Christian Borntraeger wrote:
>> here is a backport for 4.19 of
>> commit a3e03bc1368 ("KVM: s390: index kvm->arch.idle_mask by vcpu_idx")
>> This basically removes the kick_mask parts that were introduced with
>> kernel 5.0 and fixes up the location of the idle_mask to the older
>> place.
>>
>> FWIW, it might be a good idea to also backport
>> 8750e72a79dd ("KVM: remember position in kvm->vcpus array") to avoid
>> a performance regression for large guests (many vCPUs) when this patch
>> is applied.
>> @Paolo Bonzini, would you be ok with 8750e72a79dd in older stable releases?
> 
> Sure, I suppose you're going to send a separate backport that I can ack.

It does seem to apply when cherry-picked, but I can send it as a patch if you and Greg
prefer it that way.

Re: [PATCH 0/1] KVM: s390: backport for stable of "KVM: s390: index

[Paolo Bonzini]

On 21/09/21 10:46, Christian Borntraeger wrote:
>>> 
>> 
>> Sure, I suppose you're going to send a separate backport that I can
>> ack.
> 
> It does seem to apply when cherry-picked, but I can send it as a
> patch if you and Greg prefer it that way.

Yes, please do!  Thanks,

Paolo