| Message ID | 1384504501-19348-1-git-send-email-pingfank@linux.vnet.ibm.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On Fri, Nov 15, 2013 at 04:35:00PM +0800, Liu Ping Fan wrote: > Since kvmppc_hv_find_lock_hpte() is called from both virtmode and > realmode, so it can trigger the deadlock. > > Suppose the following scene: > > Two physical cpuM, cpuN, two VM instances A, B, each VM has a group of > vcpus. > > If on cpuM, vcpu_A_1 holds bitlock X (HPTE_V_HVLOCK), then is switched > out, and on cpuN, vcpu_A_2 try to lock X in realmode, then cpuN will be > caught in realmode for a long time. > > What makes things even worse if the following happens, > On cpuM, bitlockX is hold, on cpuN, Y is hold. > vcpu_B_2 try to lock Y on cpuM in realmode > vcpu_A_2 try to lock X on cpuN in realmode > > Oops! deadlock happens > > Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com> Reviewed-by: Paul Mackerras <paulus@samba.org>
On 16.11.2013, at 01:55, Paul Mackerras <paulus@samba.org> wrote: > On Fri, Nov 15, 2013 at 04:35:00PM +0800, Liu Ping Fan wrote: >> Since kvmppc_hv_find_lock_hpte() is called from both virtmode and >> realmode, so it can trigger the deadlock. >> >> Suppose the following scene: >> >> Two physical cpuM, cpuN, two VM instances A, B, each VM has a group of >> vcpus. >> >> If on cpuM, vcpu_A_1 holds bitlock X (HPTE_V_HVLOCK), then is switched >> out, and on cpuN, vcpu_A_2 try to lock X in realmode, then cpuN will be >> caught in realmode for a long time. >> >> What makes things even worse if the following happens, >> On cpuM, bitlockX is hold, on cpuN, Y is hold. >> vcpu_B_2 try to lock Y on cpuM in realmode >> vcpu_A_2 try to lock X on cpuN in realmode >> >> Oops! deadlock happens >> >> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com> > > Reviewed-by: Paul Mackerras <paulus@samba.org> Thanks, applied to kvm-ppc-queue. Alex
On 18.11.2013, at 16:32, Alexander Graf <agraf@suse.de> wrote: > > On 16.11.2013, at 01:55, Paul Mackerras <paulus@samba.org> wrote: > >> On Fri, Nov 15, 2013 at 04:35:00PM +0800, Liu Ping Fan wrote: >>> Since kvmppc_hv_find_lock_hpte() is called from both virtmode and >>> realmode, so it can trigger the deadlock. >>> >>> Suppose the following scene: >>> >>> Two physical cpuM, cpuN, two VM instances A, B, each VM has a group of >>> vcpus. >>> >>> If on cpuM, vcpu_A_1 holds bitlock X (HPTE_V_HVLOCK), then is switched >>> out, and on cpuN, vcpu_A_2 try to lock X in realmode, then cpuN will be >>> caught in realmode for a long time. >>> >>> What makes things even worse if the following happens, >>> On cpuM, bitlockX is hold, on cpuN, Y is hold. >>> vcpu_B_2 try to lock Y on cpuM in realmode >>> vcpu_A_2 try to lock X on cpuN in realmode >>> >>> Oops! deadlock happens >>> >>> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com> >> >> Reviewed-by: Paul Mackerras <paulus@samba.org> > > Thanks, applied to kvm-ppc-queue. Actually, I've changed my mind and moved the patch to the for-3.13 branch instead. Please make sure to CC kvm@vger on all patches you submit though. Alex
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm/book3s_64_mmu_hv.c index 842f081..abf81fe 100644 --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c @@ -473,11 +473,14 @@ static int kvmppc_mmu_book3s_64_hv_xlate(struct kvm_vcpu *vcpu, gva_t eaddr, slb_v = vcpu->kvm->arch.vrma_slb_v; } + preempt_disable(); /* Find the HPTE in the hash table */ index = kvmppc_hv_find_lock_hpte(kvm, eaddr, slb_v, HPTE_V_VALID | HPTE_V_ABSENT); - if (index < 0) + if (index < 0) { + preempt_enable(); return -ENOENT; + } hptep = (unsigned long *)(kvm->arch.hpt_virt + (index << 4)); v = hptep[0] & ~HPTE_V_HVLOCK; gr = kvm->arch.revmap[index].guest_rpte; @@ -485,6 +488,7 @@ static int kvmppc_mmu_book3s_64_hv_xlate(struct kvm_vcpu *vcpu, gva_t eaddr, /* Unlock the HPTE */ asm volatile("lwsync" : : : "memory"); hptep[0] = v; + preempt_enable(); gpte->eaddr = eaddr; gpte->vpage = ((v & HPTE_V_AVPN) << 4) | ((eaddr >> 12) & 0xfff); diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c b/arch/powerpc/kvm/book3s_hv_rm_mmu.c index 9c51544..ea17b30 100644 --- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c +++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c @@ -749,6 +749,10 @@ static int slb_base_page_shift[4] = { 20, /* 1M, unsupported */ }; +/* When called from virtmode, this func should be protected by + * preempt_disable(), otherwise, the holding of HPTE_V_HVLOCK + * can trigger deadlock issue. + */ long kvmppc_hv_find_lock_hpte(struct kvm *kvm, gva_t eaddr, unsigned long slb_v, unsigned long valid) {
Since kvmppc_hv_find_lock_hpte() is called from both virtmode and realmode, so it can trigger the deadlock. Suppose the following scene: Two physical cpuM, cpuN, two VM instances A, B, each VM has a group of vcpus. If on cpuM, vcpu_A_1 holds bitlock X (HPTE_V_HVLOCK), then is switched out, and on cpuN, vcpu_A_2 try to lock X in realmode, then cpuN will be caught in realmode for a long time. What makes things even worse if the following happens, On cpuM, bitlockX is hold, on cpuN, Y is hold. vcpu_B_2 try to lock Y on cpuM in realmode vcpu_A_2 try to lock X on cpuN in realmode Oops! deadlock happens Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com> --- v4: remove the over-engineered part and keep it simple, also add some notes. --- arch/powerpc/kvm/book3s_64_mmu_hv.c | 6 +++++- arch/powerpc/kvm/book3s_hv_rm_mmu.c | 4 ++++ 2 files changed, 9 insertions(+), 1 deletion(-)