summaryrefslogtreecommitdiffstats
path: root/arch/powerpc/kvm/book3s_64_mmu_hv.c
diff options
context:
space:
mode:
authorPaul Mackerras <paulus@ozlabs.org>2019-05-23 16:35:07 +1000
committerPaul Mackerras <paulus@ozlabs.org>2019-05-29 13:44:36 +1000
commitc395fe1d8e49a5aa03504fcacfb7c95b5a4c6e04 (patch)
tree9931ba29c07a5cc3f71ffd134c4d418e936d11c6 /arch/powerpc/kvm/book3s_64_mmu_hv.c
parentcd6c84d8f0cdc911df435bb075ba22ce3c605b07 (diff)
downloadlinux-c395fe1d8e49a5aa03504fcacfb7c95b5a4c6e04.tar.bz2
KVM: PPC: Book3S HV: Avoid touching arch.mmu_ready in XIVE release functions
Currently, kvmppc_xive_release() and kvmppc_xive_native_release() clear kvm->arch.mmu_ready and call kick_all_cpus_sync() as a way of ensuring that no vcpus are executing in the guest. However, future patches will change the mutex associated with kvm->arch.mmu_ready to a new mutex that nests inside the vcpu mutexes, making it difficult to continue to use this method. In fact, taking the vcpu mutex for a vcpu excludes execution of that vcpu, and we already take the vcpu mutex around the call to kvmppc_xive_[native_]cleanup_vcpu(). Once the cleanup function is done and we release the vcpu mutex, the vcpu can execute once again, but because we have cleared vcpu->arch.xive_vcpu, vcpu->arch.irq_type, vcpu->arch.xive_esc_vaddr and vcpu->arch.xive_esc_raddr, that vcpu will not be going into XIVE code any more. Thus, once we have cleaned up all of the vcpus, we are safe to clean up the rest of the XIVE state, and we don't need to use kvm->arch.mmu_ready to hold off vcpu execution. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Diffstat (limited to 'arch/powerpc/kvm/book3s_64_mmu_hv.c')
0 files changed, 0 insertions, 0 deletions