From: Peter Zijlstra <peterz@infradead.org>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: kvm@vger.kernel.org, Alexander Potapenko <glider@google.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
kvm-riscv@lists.infradead.org,
Oliver Upton <oliver.upton@linux.dev>,
Dave Hansen <dave.hansen@linux.intel.com>,
Jing Zhang <jingzhangos@google.com>,
Waiman Long <longman@redhat.com>,
x86@kernel.org, Kunkun Jiang <jiangkunkun@huawei.com>,
Boqun Feng <boqun.feng@gmail.com>,
Anup Patel <anup@brainfault.org>,
Albert Ou <aou@eecs.berkeley.edu>,
kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org,
Zenghui Yu <yuzenghui@huawei.com>, Borislav Petkov <bp@alien8.de>,
Alexandre Ghiti <alex@ghiti.fr>,
Keisuke Nishimura <keisuke.nishimura@inria.fr>,
Sebastian Ott <sebott@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Atish Patra <atishp@atishpatra.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Randy Dunlap <rdunlap@infradead.org>,
Will Deacon <will@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
linux-riscv@lists.infradead.org, Marc Zyngier <maz@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Joey Gouly <joey.gouly@arm.com>, Ingo Molnar <mingo@redhat.com>,
Andre Przywara <andre.przywara@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Sean Christopherson <seanjc@google.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH v2 2/4] KVM: x86: move sev_lock/unlock_vcpus_for_migration to kvm_main.c
Date: Thu, 10 Apr 2025 10:16:40 +0200 [thread overview]
Message-ID: <20250410081640.GX9833@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20250409014136.2816971-3-mlevitsk@redhat.com>
On Tue, Apr 08, 2025 at 09:41:34PM -0400, Maxim Levitsky wrote:
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 69782df3617f..71c0d8c35b4b 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1368,6 +1368,77 @@ static int kvm_vm_release(struct inode *inode, struct file *filp)
> return 0;
> }
>
> +
> +/*
> + * Lock all VM vCPUs.
> + * Can be used nested (to lock vCPUS of two VMs for example)
> + */
> +int kvm_lock_all_vcpus_nested(struct kvm *kvm, bool trylock, unsigned int role)
> +{
> + struct kvm_vcpu *vcpu;
> + unsigned long i, j;
> +
> + lockdep_assert_held(&kvm->lock);
> +
> + kvm_for_each_vcpu(i, vcpu, kvm) {
> +
> + if (trylock && !mutex_trylock_nested(&vcpu->mutex, role))
> + goto out_unlock;
> + else if (!trylock && mutex_lock_killable_nested(&vcpu->mutex, role))
> + goto out_unlock;
> +
> +#ifdef CONFIG_PROVE_LOCKING
> + if (!i)
> + /*
> + * Reset the role to one that avoids colliding with
> + * the role used for the first vcpu mutex.
> + */
> + role = MAX_LOCK_DEPTH - 1;
> + else
> + mutex_release(&vcpu->mutex.dep_map, _THIS_IP_);
> +#endif
> + }
This code is all sorts of terrible.
Per the lockdep_assert_held() above, you serialize all these locks by
holding that lock, this means you can be using the _nest_lock()
annotation.
Also, the original code didn't have this trylock nonsense, and the
Changelog doesn't mention this -- in fact the Changelog claims no
change, which is patently false.
Anyway, please write like:
kvm_for_each_vcpu(i, vcpu, kvm) {
if (mutex_lock_killable_nest_lock(&vcpu->mutex, &kvm->lock))
goto unlock;
}
return 0;
unlock:
kvm_for_each_vcpu(j, vcpu, kvm) {
if (j == i)
break;
mutex_unlock(&vcpu->mutex);
}
return -EINTR;
And yes, you'll have to add mutex_lock_killable_nest_lock(), but that
should be trivial.
--
kvm-riscv mailing list
kvm-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kvm-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: kvm@vger.kernel.org, Alexander Potapenko <glider@google.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
kvm-riscv@lists.infradead.org,
Oliver Upton <oliver.upton@linux.dev>,
Dave Hansen <dave.hansen@linux.intel.com>,
Jing Zhang <jingzhangos@google.com>,
Waiman Long <longman@redhat.com>,
x86@kernel.org, Kunkun Jiang <jiangkunkun@huawei.com>,
Boqun Feng <boqun.feng@gmail.com>,
Anup Patel <anup@brainfault.org>,
Albert Ou <aou@eecs.berkeley.edu>,
kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org,
Zenghui Yu <yuzenghui@huawei.com>, Borislav Petkov <bp@alien8.de>,
Alexandre Ghiti <alex@ghiti.fr>,
Keisuke Nishimura <keisuke.nishimura@inria.fr>,
Sebastian Ott <sebott@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Atish Patra <atishp@atishpatra.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Randy Dunlap <rdunlap@infradead.org>,
Will Deacon <will@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
linux-riscv@lists.infradead.org, Marc Zyngier <maz@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Joey Gouly <joey.gouly@arm.com>, Ingo Molnar <mingo@redhat.com>,
Andre Przywara <andre.przywara@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Sean Christopherson <seanjc@google.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH v2 2/4] KVM: x86: move sev_lock/unlock_vcpus_for_migration to kvm_main.c
Date: Thu, 10 Apr 2025 10:16:40 +0200 [thread overview]
Message-ID: <20250410081640.GX9833@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20250409014136.2816971-3-mlevitsk@redhat.com>
On Tue, Apr 08, 2025 at 09:41:34PM -0400, Maxim Levitsky wrote:
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 69782df3617f..71c0d8c35b4b 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1368,6 +1368,77 @@ static int kvm_vm_release(struct inode *inode, struct file *filp)
> return 0;
> }
>
> +
> +/*
> + * Lock all VM vCPUs.
> + * Can be used nested (to lock vCPUS of two VMs for example)
> + */
> +int kvm_lock_all_vcpus_nested(struct kvm *kvm, bool trylock, unsigned int role)
> +{
> + struct kvm_vcpu *vcpu;
> + unsigned long i, j;
> +
> + lockdep_assert_held(&kvm->lock);
> +
> + kvm_for_each_vcpu(i, vcpu, kvm) {
> +
> + if (trylock && !mutex_trylock_nested(&vcpu->mutex, role))
> + goto out_unlock;
> + else if (!trylock && mutex_lock_killable_nested(&vcpu->mutex, role))
> + goto out_unlock;
> +
> +#ifdef CONFIG_PROVE_LOCKING
> + if (!i)
> + /*
> + * Reset the role to one that avoids colliding with
> + * the role used for the first vcpu mutex.
> + */
> + role = MAX_LOCK_DEPTH - 1;
> + else
> + mutex_release(&vcpu->mutex.dep_map, _THIS_IP_);
> +#endif
> + }
This code is all sorts of terrible.
Per the lockdep_assert_held() above, you serialize all these locks by
holding that lock, this means you can be using the _nest_lock()
annotation.
Also, the original code didn't have this trylock nonsense, and the
Changelog doesn't mention this -- in fact the Changelog claims no
change, which is patently false.
Anyway, please write like:
kvm_for_each_vcpu(i, vcpu, kvm) {
if (mutex_lock_killable_nest_lock(&vcpu->mutex, &kvm->lock))
goto unlock;
}
return 0;
unlock:
kvm_for_each_vcpu(j, vcpu, kvm) {
if (j == i)
break;
mutex_unlock(&vcpu->mutex);
}
return -EINTR;
And yes, you'll have to add mutex_lock_killable_nest_lock(), but that
should be trivial.
WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: kvm@vger.kernel.org, Alexander Potapenko <glider@google.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
kvm-riscv@lists.infradead.org,
Oliver Upton <oliver.upton@linux.dev>,
Dave Hansen <dave.hansen@linux.intel.com>,
Jing Zhang <jingzhangos@google.com>,
Waiman Long <longman@redhat.com>,
x86@kernel.org, Kunkun Jiang <jiangkunkun@huawei.com>,
Boqun Feng <boqun.feng@gmail.com>,
Anup Patel <anup@brainfault.org>,
Albert Ou <aou@eecs.berkeley.edu>,
kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org,
Zenghui Yu <yuzenghui@huawei.com>, Borislav Petkov <bp@alien8.de>,
Alexandre Ghiti <alex@ghiti.fr>,
Keisuke Nishimura <keisuke.nishimura@inria.fr>,
Sebastian Ott <sebott@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Atish Patra <atishp@atishpatra.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Randy Dunlap <rdunlap@infradead.org>,
Will Deacon <will@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
linux-riscv@lists.infradead.org, Marc Zyngier <maz@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Joey Gouly <joey.gouly@arm.com>, Ingo Molnar <mingo@redhat.com>,
Andre Przywara <andre.przywara@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Sean Christopherson <seanjc@google.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH v2 2/4] KVM: x86: move sev_lock/unlock_vcpus_for_migration to kvm_main.c
Date: Thu, 10 Apr 2025 10:16:40 +0200 [thread overview]
Message-ID: <20250410081640.GX9833@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20250409014136.2816971-3-mlevitsk@redhat.com>
On Tue, Apr 08, 2025 at 09:41:34PM -0400, Maxim Levitsky wrote:
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 69782df3617f..71c0d8c35b4b 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1368,6 +1368,77 @@ static int kvm_vm_release(struct inode *inode, struct file *filp)
> return 0;
> }
>
> +
> +/*
> + * Lock all VM vCPUs.
> + * Can be used nested (to lock vCPUS of two VMs for example)
> + */
> +int kvm_lock_all_vcpus_nested(struct kvm *kvm, bool trylock, unsigned int role)
> +{
> + struct kvm_vcpu *vcpu;
> + unsigned long i, j;
> +
> + lockdep_assert_held(&kvm->lock);
> +
> + kvm_for_each_vcpu(i, vcpu, kvm) {
> +
> + if (trylock && !mutex_trylock_nested(&vcpu->mutex, role))
> + goto out_unlock;
> + else if (!trylock && mutex_lock_killable_nested(&vcpu->mutex, role))
> + goto out_unlock;
> +
> +#ifdef CONFIG_PROVE_LOCKING
> + if (!i)
> + /*
> + * Reset the role to one that avoids colliding with
> + * the role used for the first vcpu mutex.
> + */
> + role = MAX_LOCK_DEPTH - 1;
> + else
> + mutex_release(&vcpu->mutex.dep_map, _THIS_IP_);
> +#endif
> + }
This code is all sorts of terrible.
Per the lockdep_assert_held() above, you serialize all these locks by
holding that lock, this means you can be using the _nest_lock()
annotation.
Also, the original code didn't have this trylock nonsense, and the
Changelog doesn't mention this -- in fact the Changelog claims no
change, which is patently false.
Anyway, please write like:
kvm_for_each_vcpu(i, vcpu, kvm) {
if (mutex_lock_killable_nest_lock(&vcpu->mutex, &kvm->lock))
goto unlock;
}
return 0;
unlock:
kvm_for_each_vcpu(j, vcpu, kvm) {
if (j == i)
break;
mutex_unlock(&vcpu->mutex);
}
return -EINTR;
And yes, you'll have to add mutex_lock_killable_nest_lock(), but that
should be trivial.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2025-04-10 8:46 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-09 1:41 [PATCH v2 0/4] KVM: extract lock_all_vcpus/unlock_all_vcpus Maxim Levitsky
2025-04-09 1:41 ` Maxim Levitsky
2025-04-09 1:41 ` Maxim Levitsky
2025-04-09 1:41 ` [PATCH v2 1/4] locking/mutex: implement mutex_trylock_nested Maxim Levitsky
2025-04-09 1:41 ` Maxim Levitsky
2025-04-09 1:41 ` Maxim Levitsky
2025-04-10 8:04 ` Peter Zijlstra
2025-04-10 8:04 ` Peter Zijlstra
2025-04-10 8:04 ` Peter Zijlstra
2025-04-09 1:41 ` [PATCH v2 2/4] KVM: x86: move sev_lock/unlock_vcpus_for_migration to kvm_main.c Maxim Levitsky
2025-04-09 1:41 ` Maxim Levitsky
2025-04-09 1:41 ` Maxim Levitsky
2025-04-09 13:47 ` Waiman Long
2025-04-09 13:47 ` Waiman Long
2025-04-09 13:47 ` Waiman Long
2025-04-09 20:45 ` Oliver Upton
2025-04-09 20:45 ` Oliver Upton
2025-04-09 20:45 ` Oliver Upton
2025-04-10 8:16 ` Peter Zijlstra [this message]
2025-04-10 8:16 ` Peter Zijlstra
2025-04-10 8:16 ` Peter Zijlstra
2025-04-16 17:48 ` Paolo Bonzini
2025-04-16 17:48 ` Paolo Bonzini
2025-04-16 17:48 ` Paolo Bonzini
2025-04-16 18:50 ` Peter Zijlstra
2025-04-16 18:50 ` Peter Zijlstra
2025-04-16 18:50 ` Peter Zijlstra
2025-04-17 9:53 ` Paolo Bonzini
2025-04-17 9:53 ` Paolo Bonzini
2025-04-17 9:53 ` Paolo Bonzini
2025-04-09 1:41 ` [PATCH v2 3/4] KVM: arm64: switch to using kvm_lock/unlock_all_vcpus Maxim Levitsky
2025-04-09 1:41 ` Maxim Levitsky
2025-04-09 1:41 ` Maxim Levitsky
2025-04-09 1:41 ` [PATCH v2 4/4] RISC-V: KVM: switch to kvm_lock/unlock_all_vcpus Maxim Levitsky
2025-04-09 1:41 ` Maxim Levitsky
2025-04-09 1:41 ` Maxim Levitsky
2025-04-09 19:53 ` [PATCH v2 0/4] KVM: extract lock_all_vcpus/unlock_all_vcpus Sean Christopherson
2025-04-09 19:53 ` Sean Christopherson
2025-04-09 19:53 ` Sean Christopherson
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=20250410081640.GX9833@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=alex@ghiti.fr \
--cc=andre.przywara@arm.com \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=atishp@atishpatra.org \
--cc=bhelgaas@google.com \
--cc=boqun.feng@gmail.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=glider@google.com \
--cc=hpa@zytor.com \
--cc=jiangkunkun@huawei.com \
--cc=jingzhangos@google.com \
--cc=joey.gouly@arm.com \
--cc=keisuke.nishimura@inria.fr \
--cc=kvm-riscv@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=longman@redhat.com \
--cc=maz@kernel.org \
--cc=mingo@redhat.com \
--cc=mlevitsk@redhat.com \
--cc=oliver.upton@linux.dev \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=pbonzini@redhat.com \
--cc=rdunlap@infradead.org \
--cc=seanjc@google.com \
--cc=sebott@redhat.com \
--cc=suzuki.poulose@arm.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=yuzenghui@huawei.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.