Christian Ehrhardt wrote:
Avi Kivity wrote:
ehrhardt@xxxxxxxxxxxxxxxxxx wrote:
From: Christian Ehrhardt <ehrhardt@xxxxxxxxxxxxxxxxxx>
[...]
- /* 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.
I assume that the IPI on x86 is a implicit consequence of the
smp_call_function_many function, but I think this doesn't work that
way for us. The kick implied by that call would be recieved, but not
reach the code the checke vcpu->request. I could add that behaviour,
but that could make our normal interrupt handling much slower.
Therefore I don't want to call that function, but on the other hand I
like the "skip if the request is already set" functionality and think
about adding that in my loop.
For now I added the optimization to skip kicking vcpus out of guest that
had the request bit already set to the s390 specific loop (sent as v2 in
a few minutes).
We might one day consider standardizing some generic kickout levels e.g.
kick to "inner loop", "arch vcpu run", "generic vcpu run", "userspace",
... whatever levels fit *all* our use cases. And then let that kicks be
implemented in an kvm_arch_* backend as it might be very different how
they behave on different architectures. In case an architecture cannot
achive reaching the specified kickout level it has to kick to the next
available upper level which eventually will reach the desired step on
the way to re-run the vcpu.
Alltogether this should lead to a much more reliable and transparent
interface that finally should be used all across the generic code.
--
Grüsse / regards, Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
--
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
