ehrhardt@xxxxxxxxxxxxxxxxxx wrote:
From: Christian Ehrhardt <ehrhardt@xxxxxxxxxxxxxxxxxx>
This patch relocates the variables kvm-s390 uses to track guest mem addr/size.
As discussed dropping the variables at struct kvm_arch level allows to use the
common vcpu->request based mechanism to reload guest memory if e.g. changes
via set_memory_region.
The kick mechanism introduced in this series is used to ensure running vcpus
leave guest state to catch the update.
rerun_vcpu:
+ if (vcpu->requests)
+ if (test_and_clear_bit(KVM_REQ_MMU_RELOAD, &vcpu->requests))
+ kvm_s390_vcpu_set_mem(vcpu);
+
/* verify, that memory has been registered */
- if (!vcpu->kvm->arch.guest_memsize) {
+ if (!vcpu->arch.sie_block->gmslm) {
vcpu_put(vcpu);
+ VCPU_EVENT(vcpu, 3, "%s", "no memory registered to run vcpu");
return -EINVAL;
}
x86 uses a double check: first we check vcpu->requests outside atomic
context, then we enter the critical section and check again for signals
and vcpu->requests.
This allows us (a) to do naughty things in vcpu->requests handlers, (b)
keep the critical section short.
Does this apply here?
- /* update sie control blocks, and unlock all vcpus */
+ /* request update of sie control block for all available vcpus */
for (i = 0; i < KVM_MAX_VCPUS; ++i) {
if (kvm->vcpus[i]) {
- kvm->vcpus[i]->arch.sie_block->gmsor =
- kvm->arch.guest_origin;
- kvm->vcpus[i]->arch.sie_block->gmslm =
- kvm->arch.guest_memsize +
- kvm->arch.guest_origin +
- VIRTIODESCSPACE - 1ul;
- mutex_unlock(&kvm->vcpus[i]->mutex);
+ set_bit(KVM_REQ_MMU_RELOAD, &kvm->vcpus[i]->requests);
+ kvm_s390_inject_sigp_stop(kvm->vcpus[i],
+ ACTION_RELOADVCPU_ON_STOP);
}
}
There already exists a loop which does this, see
make_all_cpus_request(). It uses an IPI (Marcelo, can't it use the
reschedule interrupt?). It has a couple of optimizations -- if the
request is already set, it skips the IPI, and it avoids the IPI for
vcpus out of guest mode. Maybe it could fit s390 too.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
