From: Sean Christopherson <seanjc@google.com>
To: Peter Gonda <pgonda@google.com>
Cc: kvm@vger.kernel.org, John Sperbeck <jsperbeck@google.com>,
David Rientjes <rientjes@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: SEV: Mark nested locking of vcpu->lock
Date: Mon, 4 Apr 2022 20:35:09 +0000 [thread overview]
Message-ID: <YktWfUbjz27OdbUA@google.com> (raw)
In-Reply-To: <20220404194605.1569855-1-pgonda@google.com>
On Mon, Apr 04, 2022, Peter Gonda wrote:
> svm_vm_migrate_from() uses sev_lock_vcpus_for_migration() to lock all
> source and target vcpu->locks. Mark the nested subclasses to avoid false
> positives from lockdep.
>
> Fixes: b56639318bb2b ("KVM: SEV: Add support for SEV intra host migration")
> Reported-by: John Sperbeck<jsperbeck@google.com>
> Suggested-by: David Rientjes <rientjes@google.com>
> Signed-off-by: Peter Gonda <pgonda@google.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Sean Christopherson <seanjc@google.com>
> Cc: kvm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
>
> Tested by running sev_migrate_tests with lockdep enabled. Before we see
> a warning from sev_lock_vcpus_for_migration(). After we get no warnings.
>
> ---
> arch/x86/kvm/svm/sev.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 75fa6dd268f0..8f77421c1c4b 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -1591,15 +1591,16 @@ static void sev_unlock_two_vms(struct kvm *dst_kvm, struct kvm *src_kvm)
> atomic_set_release(&src_sev->migration_in_progress, 0);
> }
>
> -
> -static int sev_lock_vcpus_for_migration(struct kvm *kvm)
> +static int sev_lock_vcpus_for_migration(struct kvm *kvm, unsigned int *subclass)
> {
> struct kvm_vcpu *vcpu;
> unsigned long i, j;
>
> kvm_for_each_vcpu(i, vcpu, kvm) {
> - if (mutex_lock_killable(&vcpu->mutex))
> + if (mutex_lock_killable_nested(&vcpu->mutex, *subclass))
> goto out_unlock;
> +
> + ++(*subclass);
This is rather gross, and I'm guessing it adds extra work for the non-lockdep
case, assuming the compiler isn't so clever that it can figure out that the result
is never used. Not that this is a hot path...
Does each lock actually need a separate subclass? If so, why don't the other
paths that lock all vCPUs complain?
If differentiating the two VMs is sufficient, then we can pass in SINGLE_DEPTH_NESTING
for the second round of locks. If a per-vCPU subclass is required, we can use the
vCPU index and assign evens to one and odds to the other, e.g. this should work and
compiles to a nop when LOCKDEP is disabled (compile tested only). It's still gross,
but we could pretty it up, e.g. add defines for the 0/1 param.
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 75fa6dd268f0..9be35902b809 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -1591,14 +1591,13 @@ static void sev_unlock_two_vms(struct kvm *dst_kvm, struct kvm *src_kvm)
atomic_set_release(&src_sev->migration_in_progress, 0);
}
-
-static int sev_lock_vcpus_for_migration(struct kvm *kvm)
+static int sev_lock_vcpus_for_migration(struct kvm *kvm, int mod)
{
struct kvm_vcpu *vcpu;
unsigned long i, j;
kvm_for_each_vcpu(i, vcpu, kvm) {
- if (mutex_lock_killable(&vcpu->mutex))
+ if (mutex_lock_killable_nested(&vcpu->mutex, i * 2 + mod))
goto out_unlock;
}
@@ -1745,10 +1744,10 @@ int sev_vm_move_enc_context_from(struct kvm *kvm, unsigned int source_fd)
charged = true;
}
- ret = sev_lock_vcpus_for_migration(kvm);
+ ret = sev_lock_vcpus_for_migration(kvm, 0);
if (ret)
goto out_dst_cgroup;
- ret = sev_lock_vcpus_for_migration(source_kvm);
+ ret = sev_lock_vcpus_for_migration(source_kvm, 1);
if (ret)
goto out_dst_vcpu;
next prev parent reply other threads:[~2022-04-04 21:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-04 19:46 [PATCH] KVM: SEV: Mark nested locking of vcpu->lock Peter Gonda
2022-04-04 20:35 ` Sean Christopherson [this message]
2022-04-04 21:51 ` Peter Gonda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YktWfUbjz27OdbUA@google.com \
--to=seanjc@google.com \
--cc=jsperbeck@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=pgonda@google.com \
--cc=rientjes@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.