Thanks, this is beautiful enough. :) Hmm, the combination of 6c7caebc26c5 ("KVM: introduce kvm->created_vcpus", 2016-06-16) and 4c5ea0a9cd02 ("locking/static_key: Fix concurrent static_key_slow_inc()", 2016-06-24) should have fixed it for good. Is the ENABLE_CAP necessary to reproduce? Then, the bug is simply that the ENABLE_CAP should have failed without an irqchip (the KVM_CREATE_IRQCHIP in turn must have failed with EINVAL).ENABLE_CAP is necessary to reproduce.Now I see what Paolo means, how about something like below: diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 51ccfe0..7ec22e2 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -3337,7 +3337,10 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu, switch (cap->cap) { case KVM_CAP_HYPERV_SYNIC: - return kvm_hv_activate_synic(vcpu); + if (!irqchip_in_kernel(vcpu->kvm)) + return -EINVAL; + else
You can simply drop the else and return directly. Can't really say if this is the right fix, my first thought was that a request has been set although it should never have been set for that VCPU. Maybe that is an effect of synic being activated (because synic code unconditionally later on sets the request). Fixing the cause of the request seems better than fixing up the result. -- David -- 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
