summaryrefslogtreecommitdiffstats
path: root/arch
diff options
context:
space:
mode:
authorJulius Niedworok <jniedwor@linux.vnet.ibm.com>2016-08-03 16:39:55 +0200
committerChristian Borntraeger <borntraeger@de.ibm.com>2016-08-12 09:11:08 +0200
commitaca411a4b17a4aebe14ecdf253373db5b7ee6058 (patch)
treee3457792ac4e54969e665477ebbbe8c6869ed9b9 /arch
parentKVM: s390: set the prefix initially properly (diff)
downloadlinux-aca411a4b17a4aebe14ecdf253373db5b7ee6058.tar.xz
linux-aca411a4b17a4aebe14ecdf253373db5b7ee6058.zip
KVM: s390: reset KVM_REQ_MMU_RELOAD if mapping the prefix failed
When triggering KVM_RUN without a user memory region being mapped (KVM_SET_USER_MEMORY_REGION) a validity intercept occurs. This could happen, if the user memory region was not mapped initially or if it was unmapped after the vcpu is initialized. The function kvm_s390_handle_requests checks for the KVM_REQ_MMU_RELOAD bit. The check function always clears this bit. If gmap_mprotect_notify returns an error code, the mapping failed, but the KVM_REQ_MMU_RELOAD was not set anymore. So the next time kvm_s390_handle_requests is called, the execution would fall trough the check for KVM_REQ_MMU_RELOAD. The bit needs to be resetted, if gmap_mprotect_notify returns an error code. Resetting the bit with kvm_make_request(KVM_REQ_MMU_RELOAD, vcpu) fixes the bug. Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by: Julius Niedworok <jniedwor@linux.vnet.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Diffstat (limited to 'arch')
-rw-r--r--arch/s390/kvm/kvm-s390.c4
1 files changed, 3 insertions, 1 deletions
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index e63f6ed0a936..f142215ed30d 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -2362,8 +2362,10 @@ retry:
rc = gmap_mprotect_notify(vcpu->arch.gmap,
kvm_s390_get_prefix(vcpu),
PAGE_SIZE * 2, PROT_WRITE);
- if (rc)
+ if (rc) {
+ kvm_make_request(KVM_REQ_MMU_RELOAD, vcpu);
return rc;
+ }
goto retry;
}