| commit | f9530c32420fff941b7bc8bb5d90310eecab5a96 | |
| author | Christian Borntraeger <borntraeger@de.ibm.com> | |
| Mon, 19 Sep 2016 11:39:42 +0000 (19 13:39 +0200) | ||
| committer | Christian Borntraeger <borntraeger@de.ibm.com> | |
| Wed, 28 Sep 2016 11:24:51 +0000 (28 13:24 +0200) | ||
| tree | 71dfffe8cad14ba939ea04632e5e29fda4c2a2e0 | treesnapshot (tar.gz zip) |
| parent | bfcec59a23f42dcac18a434bd48bd60d6fc0e563 | commitdiff |
s390x/kvm: Fix potential deadlock in sigp handling
If two VCPUs exit at the same time and target each other
with a sigp, both could run into a deadlock as run_on_cpu
on CPU0 will free the BQL when starting the CPU1 target routine.
CPU1 will run its sigp initiater for CPU0 before handling
the run_on_cpu requests, thus resulting in a dead lock.
As all qemu SIGPs are slow path anway we can use a big sigp
lock and allow only one SIGP for the guest at a time. We will
return condition code 2 (BUSY) on contention to the guest.
Reported-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
If two VCPUs exit at the same time and target each other
with a sigp, both could run into a deadlock as run_on_cpu
on CPU0 will free the BQL when starting the CPU1 target routine.
CPU1 will run its sigp initiater for CPU0 before handling
the run_on_cpu requests, thus resulting in a dead lock.
As all qemu SIGPs are slow path anway we can use a big sigp
lock and allow only one SIGP for the guest at a time. We will
return condition code 2 (BUSY) on contention to the guest.
Reported-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
| target-s390x/kvm.c | diffblobblamehistory |