On Mon, May 25, 2009 at 01:40:49PM +0200, ehrhardt@xxxxxxxxxxxxxxxxxx wrote: > From: Christian Ehrhardt <ehrhardt@xxxxxxxxxxxxxxxxxx> > > To ensure vcpu's come out of guest context in certain cases this patch adds a > s390 specific way to kick them out of guest context. Currently it kicks them > out to rerun the vcpu_run path in the s390 code, but the mechanism itself is > expandable and with a new flag we could also add e.g. kicks to userspace etc. > > Signed-off-by: Christian Ehrhardt <ehrhardt@xxxxxxxxxxxxxxxxxx> "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." That would be ideal, yes. Two things make_all_requests handles: 1) It disables preemption with get_cpu(), so it can reliably check for cpu id. Somehow you don't need that for s390 when kicking multiple vcpus? 2) It uses smp_call_function_many(wait=1), which guarantees that by the time make_all_requests returns no vcpus will be using stale data (the remote vcpus will have executed ack_flush). If smp_call_function_many is hidden behind kvm_arch_kick_vcpus, can you make use of make_all_requests for S390 (without the smp_call_function performance impact you mentioned) ? For x86 we can further optimize make_all_requests by checking REQ_KICK, and kvm_arch_kick_vcpus would be a good place for that. And the kickout levels idea you mentioned can come later, as an optimization? -- 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
