From: Sean Christopherson <seanjc@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Juergen Gross <jgross@suse.com>, Anup Patel <anup.patel@wdc.com>,
Janosch Frank <frankja@linux.ibm.com>,
kvm@vger.kernel.org,
Christian Borntraeger <borntraeger@de.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Huacai Chen <chenhuacai@kernel.org>,
David Hildenbrand <david@redhat.com>,
linux-mips@vger.kernel.org, Nicholas Piggin <npiggin@gmail.com>,
Atish Patra <atish.patra@wdc.com>,
Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
Paul Mackerras <paulus@samba.org>,
Paolo Bonzini <pbonzini@redhat.com>,
kernel-team@android.com,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
linuxppc-dev@lists.ozlabs.org, kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH 1/5] KVM: Move wiping of the kvm->vcpus array to common code
Date: Fri, 5 Nov 2021 20:12:12 +0000 [thread overview]
Message-ID: <YYWQHBwD4nBLo9qi@google.com> (raw)
In-Reply-To: <20211105192101.3862492-2-maz@kernel.org>
On Fri, Nov 05, 2021, Marc Zyngier wrote:
> All architectures have similar loops iterating over the vcpus,
> freeing one vcpu at a time, and eventually wiping the reference
> off the vcpus array. They are also inconsistently taking
> the kvm->lock mutex when wiping the references from the array.
...
> +void kvm_destroy_vcpus(struct kvm *kvm)
> +{
> + unsigned int i;
> + struct kvm_vcpu *vcpu;
> +
> + kvm_for_each_vcpu(i, vcpu, kvm)
> + kvm_vcpu_destroy(vcpu);
> +
> + mutex_lock(&kvm->lock);
But why is kvm->lock taken here? Unless I'm overlooking an arch, everyone calls
this from kvm_arch_destroy_vm(), in which case this is the only remaining reference
to @kvm. And if there's some magic path for which that's not true, I don't see how
it can possibly be safe to call kvm_vcpu_destroy() without holding kvm->lock, or
how this would guarantee that all vCPUs have actually been destroyed before nullifying
the array.
> + for (i = 0; i < atomic_read(&kvm->online_vcpus); i++)
> + kvm->vcpus[i] = NULL;
> +
> + atomic_set(&kvm->online_vcpus, 0);
> + mutex_unlock(&kvm->lock);
> +}
> +EXPORT_SYMBOL_GPL(kvm_destroy_vcpus);
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kvm@vger.kernel.org, linux-mips@vger.kernel.org,
kvmarm@lists.cs.columbia.edu, linuxppc-dev@lists.ozlabs.org,
Huacai Chen <chenhuacai@kernel.org>,
Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
Anup Patel <anup.patel@wdc.com>,
Atish Patra <atish.patra@wdc.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Janosch Frank <frankja@linux.ibm.com>,
David Hildenbrand <david@redhat.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Juergen Gross <jgross@suse.com>,
Nicholas Piggin <npiggin@gmail.com>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
kernel-team@android.com
Subject: Re: [PATCH 1/5] KVM: Move wiping of the kvm->vcpus array to common code
Date: Fri, 5 Nov 2021 20:12:12 +0000 [thread overview]
Message-ID: <YYWQHBwD4nBLo9qi@google.com> (raw)
In-Reply-To: <20211105192101.3862492-2-maz@kernel.org>
On Fri, Nov 05, 2021, Marc Zyngier wrote:
> All architectures have similar loops iterating over the vcpus,
> freeing one vcpu at a time, and eventually wiping the reference
> off the vcpus array. They are also inconsistently taking
> the kvm->lock mutex when wiping the references from the array.
...
> +void kvm_destroy_vcpus(struct kvm *kvm)
> +{
> + unsigned int i;
> + struct kvm_vcpu *vcpu;
> +
> + kvm_for_each_vcpu(i, vcpu, kvm)
> + kvm_vcpu_destroy(vcpu);
> +
> + mutex_lock(&kvm->lock);
But why is kvm->lock taken here? Unless I'm overlooking an arch, everyone calls
this from kvm_arch_destroy_vm(), in which case this is the only remaining reference
to @kvm. And if there's some magic path for which that's not true, I don't see how
it can possibly be safe to call kvm_vcpu_destroy() without holding kvm->lock, or
how this would guarantee that all vCPUs have actually been destroyed before nullifying
the array.
> + for (i = 0; i < atomic_read(&kvm->online_vcpus); i++)
> + kvm->vcpus[i] = NULL;
> +
> + atomic_set(&kvm->online_vcpus, 0);
> + mutex_unlock(&kvm->lock);
> +}
> +EXPORT_SYMBOL_GPL(kvm_destroy_vcpus);
WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Juergen Gross <jgross@suse.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
Anup Patel <anup.patel@wdc.com>,
Janosch Frank <frankja@linux.ibm.com>,
kvm@vger.kernel.org,
Christian Borntraeger <borntraeger@de.ibm.com>,
Huacai Chen <chenhuacai@kernel.org>,
David Hildenbrand <david@redhat.com>,
linux-mips@vger.kernel.org, Nicholas Piggin <npiggin@gmail.com>,
Atish Patra <atish.patra@wdc.com>,
Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
Paul Mackerras <paulus@samba.org>,
James Morse <james.morse@arm.com>,
Paolo Bonzini <pbonzini@redhat.com>,
kernel-team@android.com,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
linuxppc-dev@lists.ozlabs.org, kvmarm@lists.cs.columbia.edu,
Suzuki K Poulose <suzuki.poulose@arm.com>
Subject: Re: [PATCH 1/5] KVM: Move wiping of the kvm->vcpus array to common code
Date: Fri, 5 Nov 2021 20:12:12 +0000 [thread overview]
Message-ID: <YYWQHBwD4nBLo9qi@google.com> (raw)
In-Reply-To: <20211105192101.3862492-2-maz@kernel.org>
On Fri, Nov 05, 2021, Marc Zyngier wrote:
> All architectures have similar loops iterating over the vcpus,
> freeing one vcpu at a time, and eventually wiping the reference
> off the vcpus array. They are also inconsistently taking
> the kvm->lock mutex when wiping the references from the array.
...
> +void kvm_destroy_vcpus(struct kvm *kvm)
> +{
> + unsigned int i;
> + struct kvm_vcpu *vcpu;
> +
> + kvm_for_each_vcpu(i, vcpu, kvm)
> + kvm_vcpu_destroy(vcpu);
> +
> + mutex_lock(&kvm->lock);
But why is kvm->lock taken here? Unless I'm overlooking an arch, everyone calls
this from kvm_arch_destroy_vm(), in which case this is the only remaining reference
to @kvm. And if there's some magic path for which that's not true, I don't see how
it can possibly be safe to call kvm_vcpu_destroy() without holding kvm->lock, or
how this would guarantee that all vCPUs have actually been destroyed before nullifying
the array.
> + for (i = 0; i < atomic_read(&kvm->online_vcpus); i++)
> + kvm->vcpus[i] = NULL;
> +
> + atomic_set(&kvm->online_vcpus, 0);
> + mutex_unlock(&kvm->lock);
> +}
> +EXPORT_SYMBOL_GPL(kvm_destroy_vcpus);
next prev parent reply other threads:[~2021-11-05 20:12 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-05 19:20 [PATCH 0/5] KVM: Turn the vcpu array into an xarray Marc Zyngier
2021-11-05 19:20 ` Marc Zyngier
2021-11-05 19:20 ` Marc Zyngier
2021-11-05 19:20 ` [PATCH 1/5] KVM: Move wiping of the kvm->vcpus array to common code Marc Zyngier
2021-11-05 19:20 ` Marc Zyngier
2021-11-05 19:20 ` Marc Zyngier
2021-11-05 20:12 ` Sean Christopherson [this message]
2021-11-05 20:12 ` Sean Christopherson
2021-11-05 20:12 ` Sean Christopherson
2021-11-06 11:17 ` Marc Zyngier
2021-11-06 11:17 ` Marc Zyngier
2021-11-06 11:17 ` Marc Zyngier
2021-11-16 13:49 ` Paolo Bonzini
2021-11-16 13:49 ` Paolo Bonzini
2021-11-16 13:49 ` Paolo Bonzini
2021-11-08 12:12 ` Claudio Imbrenda
2021-11-08 12:12 ` Claudio Imbrenda
2021-11-08 12:12 ` Claudio Imbrenda
2021-11-05 19:20 ` [PATCH 2/5] KVM: mips: Use kvm_get_vcpu() instead of open-coded access Marc Zyngier
2021-11-05 19:20 ` Marc Zyngier
2021-11-05 19:20 ` Marc Zyngier
2021-11-06 15:56 ` Philippe Mathieu-Daudé
2021-11-06 15:56 ` Philippe Mathieu-Daudé
2021-11-06 15:56 ` Philippe Mathieu-Daudé
2021-11-05 19:20 ` [PATCH 3/5] KVM: s390: " Marc Zyngier
2021-11-05 19:20 ` Marc Zyngier
2021-11-05 19:20 ` Marc Zyngier
2021-11-08 12:13 ` Claudio Imbrenda
2021-11-08 12:13 ` Claudio Imbrenda
2021-11-08 12:13 ` Claudio Imbrenda
2021-11-05 19:21 ` [PATCH 4/5] KVM: x86: " Marc Zyngier
2021-11-05 19:21 ` Marc Zyngier
2021-11-05 19:21 ` Marc Zyngier
2021-11-05 20:03 ` Sean Christopherson
2021-11-05 20:03 ` Sean Christopherson
2021-11-05 20:03 ` Sean Christopherson
2021-11-16 14:04 ` Paolo Bonzini
2021-11-16 14:04 ` Paolo Bonzini
2021-11-16 14:04 ` Paolo Bonzini
2021-11-16 16:07 ` Sean Christopherson
2021-11-16 16:07 ` Sean Christopherson
2021-11-16 16:07 ` Sean Christopherson
2021-11-16 16:48 ` Paolo Bonzini
2021-11-16 16:48 ` Paolo Bonzini
2021-11-16 16:48 ` Paolo Bonzini
2021-11-05 19:21 ` [PATCH 5/5] KVM: Convert the kvm->vcpus array to a xarray Marc Zyngier
2021-11-05 19:21 ` Marc Zyngier
2021-11-05 19:21 ` Marc Zyngier
2021-11-05 20:21 ` Sean Christopherson
2021-11-05 20:21 ` Sean Christopherson
2021-11-05 20:21 ` Sean Christopherson
2021-11-06 11:48 ` Marc Zyngier
2021-11-06 11:48 ` Marc Zyngier
2021-11-06 11:48 ` Marc Zyngier
2021-11-08 8:23 ` Marc Zyngier
2021-11-08 8:23 ` Marc Zyngier
2021-11-08 8:23 ` Marc Zyngier
2021-11-16 14:13 ` [PATCH 0/5] KVM: Turn the vcpu array into an xarray Juergen Gross
2021-11-16 14:13 ` Juergen Gross
2021-11-16 14:13 ` Juergen Gross
2021-11-16 14:21 ` Paolo Bonzini
2021-11-16 14:21 ` Paolo Bonzini
2021-11-16 14:21 ` Paolo Bonzini
2021-11-16 14:54 ` Juergen Gross
2021-11-16 14:54 ` Juergen Gross
2021-11-16 14:54 ` Juergen Gross
2021-11-16 15:03 ` Paolo Bonzini
2021-11-16 15:03 ` Paolo Bonzini
2021-11-16 15:03 ` Paolo Bonzini
2021-11-16 15:40 ` Marc Zyngier
2021-11-16 15:40 ` Marc Zyngier
2021-11-16 15:40 ` Marc Zyngier
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=YYWQHBwD4nBLo9qi@google.com \
--to=seanjc@google.com \
--cc=aleksandar.qemu.devel@gmail.com \
--cc=anup.patel@wdc.com \
--cc=atish.patra@wdc.com \
--cc=borntraeger@de.ibm.com \
--cc=chenhuacai@kernel.org \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=jgross@suse.com \
--cc=kernel-team@android.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-mips@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maz@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=paulus@samba.org \
--cc=pbonzini@redhat.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.