On Thu, 2023-01-05 at 22:23 +0000, Sean Christopherson wrote:
> This comment in kvm_xen_set_evtchn() is a tragicomedy. It explicitly calls out
> the exact case that would be problematic (Xen hypercall), but commit 2fd6df2f2b47
> ("KVM: x86/xen: intercept EVTCHNOP_send from guests") ran right past that.
>
> /*
> * For the irqfd workqueue, using the main kvm->lock mutex is
> * fine since this function is invoked from kvm_set_irq() with
> * no other lock held, no srcu. In future if it will be called
> * directly from a vCPU thread (e.g. on hypercall for an IPI)
> * then it may need to switch to using a leaf-node mutex for
> * serializing the shared_info mapping.
> */
> mutex_lock(&kvm->lock);
>
Yeah, turns out I knew that once. Sometimes I'm cleverer than other
times. I try to leave helpful notes for the other one, but he doesn't
always read them...
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
