On 1/5/23 23:23, Sean Christopherson wrote:
Ha! Case in point. The aforementioned Xen code blatantly violates KVM's locking rules: - kvm->lock is taken outside vcpu->mutex
Ouch yeah, that's not salvageable. Anything that takes kvm->lock inside kvm->srcu transitively has to be taking kvm->lock inside vcpu->mutex as well.
In abstract I don't think that "vcpu->mutex inside kvm->lock" would be a particularly problematic rule; kvm->lock critical sections are much shorter than vcpu->mutex which covers all of KVM_RUN for example, and that hints at making vcpu->mutex the *outer* mutex. However, I completely forgot the sev_lock_vcpus_for_migration case, which is the exception that... well, disproves the rule.
Fortunately, it's pretty easy to introduce a new lock just for xen.c and revert the docs patch.
Paolo
