On 09/06/2017 02:33 PM, David Hildenbrand wrote:
On 06.09.2017 00:27, Jan H. Schönherr wrote:KVM API says that KVM_RUN will return with -EINTR when a signal is pending. However, if a vCPU is in KVM_MP_STATE_UNINITIALIZED, then the return value is unconditionally -EAGAIN. Copy over some code from vcpu_run(), so that the case of a pending signal results in the expected return value. Signed-off-by: Jan H. Schönherr <jschoenh@xxxxxxxxx> --- arch/x86/kvm/x86.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 272320e..40039cd 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -7203,6 +7203,11 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run) kvm_apic_accept_events(vcpu); kvm_clear_request(KVM_REQ_UNHALT, vcpu); r = -EAGAIN; + if (signal_pending(current)) { + r = -EINTR; + vcpu->run->exit_reason = KVM_EXIT_INTR; + ++vcpu->stat.signal_exits; + } goto out; }I am not sure if this is the right thing to do. E.g. also on s390x a -EINVAL is indicated if the VCPU is stopped. If the documentation is unclear, maybe that one should be fixed. I don't see this to be relevant in practice, or is it? -EINTR will only be returned if nothing else hinders the VCPU from running.
In practice, in allows me to distinguish, whether I can reenter KVM_RUN immediately (-EAGAIN), or whether I have to check for signals first (-EINTR), or whether I need to have a look at the actual exit reason (0). Right now, KVM_RUN returns *immediately* with -EAGAIN when there is a pending signal for a vCPU thread that's in KVM_MP_STATE_UNINITIALIZED. And it does so again and again until you consume the signal in user space. Regards Jan PS: I just noticed, that the kvm_run->immediate_exit handling also does not work in this case. Instead, the vCPU thread goes to sleep in the KVM_MP_STATE_UNINITIALIZED case. (Let me prepare a patch for that...) So, I don't agree, that this is a case, where only the documentation needs a fix.
