Re: [PATCH 1/3] kvm-s390: infrastructure to kick vcpus out of guest state

[Marcelo Tosatti <mtosatti@redhat.com>]

On Mon, May 25, 2009 at 01:40:49PM +0200, ehrhardt@linux.vnet.ibm.com wrote:
> From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
> 
> 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@linux.vnet.ibm.com>

"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?