diff options
| author | Paolo Bonzini <pbonzini@redhat.com> | 2015-07-30 13:30:03 +0200 |
|---|---|---|
| committer | Paolo Bonzini <pbonzini@redhat.com> | 2015-07-30 13:30:03 +0200 |
| commit | 7307f70c6d525aa050d3027035215fb5473aa1bb (patch) | |
| tree | e0bece33b84a5585337ec592e311c84cef551590 /arch | |
| parent | 956325bd55bb020e574129c443a2c2c66a8316e7 (diff) | |
| parent | 586b7ccdb7143b6a9b975d2c6ad52b6ca5c162b9 (diff) | |
| download | linux-stable-7307f70c6d525aa050d3027035215fb5473aa1bb.tar.gz linux-stable-7307f70c6d525aa050d3027035215fb5473aa1bb.tar.bz2 linux-stable-7307f70c6d525aa050d3027035215fb5473aa1bb.zip | |
Merge tag 'kvm-s390-master-20150730' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into kvm-master
KVM: s390: bugfix for kvm/master (4.2)
Here is a bugfix for a regression that was introduced after 4.1
with the commit commit 785dbef407d8 ("KVM: s390: optimize round
trip time in request handling"). After lots of cpu hotplugs in the
guest (online/offline) sometimes a guest CPU did loop within host
KVM code. Reason was that PROG_REQUEST was set in the sie control
block, but no request was pending. This made commit 785dbef407d8
the suspect and changing that area to always reset PROG_REQUEST
did indeed fix the problem.
Special thanks to David Hildenbrand, who helped understanding the
exact sequence that led to the problem.
Diffstat (limited to 'arch')
| -rw-r--r-- | arch/s390/kvm/kvm-s390.c | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c index 2078f92d15ac..f32f843a3631 100644 --- a/arch/s390/kvm/kvm-s390.c +++ b/arch/s390/kvm/kvm-s390.c @@ -1742,10 +1742,10 @@ static bool ibs_enabled(struct kvm_vcpu *vcpu) static int kvm_s390_handle_requests(struct kvm_vcpu *vcpu) { - if (!vcpu->requests) - return 0; retry: kvm_s390_vcpu_request_handled(vcpu); + if (!vcpu->requests) + return 0; /* * We use MMU_RELOAD just to re-arm the ipte notifier for the * guest prefix page. gmap_ipte_notify will wait on the ptl lock. |