From: Sean Christopherson <seanjc@google.com>
To: Vishal Annapurve <vannapurve@google.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
pbonzini@redhat.com, mlevitsk@redhat.com, kvm@vger.kernel.org,
rick.p.edgecombe@intel.com, kirill.shutemov@linux.intel.com,
kai.huang@intel.com, reinette.chatre@intel.com,
xiaoyao.li@intel.com, tony.lindgren@linux.intel.com,
binbin.wu@linux.intel.com, isaku.yamahata@intel.com,
linux-kernel@vger.kernel.org, yan.y.zhao@intel.com,
chao.gao@intel.com
Subject: Re: [PATCH V2 1/1] KVM: TDX: Add sub-ioctl KVM_TDX_TERMINATE_VM
Date: Fri, 18 Apr 2025 18:08:29 -0700 [thread overview]
Message-ID: <aAL3jRz3DTL8Ivhv@google.com> (raw)
In-Reply-To: <CAGtprH8EhU_XNuQUhCPonwfbhpg+faHx+CdtbSRouMA38eSGCw@mail.gmail.com>
On Fri, Apr 18, 2025, Vishal Annapurve wrote:
> On Thu, Apr 17, 2025 at 6:20 AM Adrian Hunter <adrian.hunter@intel.com> wrote:
> >
> > ...
> > +static int tdx_terminate_vm(struct kvm *kvm)
> > +{
> > + int r = 0;
> > +
> > + guard(mutex)(&kvm->lock);
> > + cpus_read_lock();
> > +
> > + if (!kvm_trylock_all_vcpus(kvm)) {
>
> Does this need to be a trylock variant? Is userspace expected to keep
> retrying this operation indefinitely?
Userspace is expected to not be stupid, i.e. not be doing things with vCPUs when
terminating the VM. This is already rather unpleasant, I'd rather not have to
think hard about what could go wrong if KVM has to wait on all vCPU mutexes.
next prev parent reply other threads:[~2025-04-19 1:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 13:19 [PATCH V2 0/1] KVM: TDX: Decrease TDX VM shutdown time Adrian Hunter
2025-04-17 13:19 ` [PATCH V2 1/1] KVM: TDX: Add sub-ioctl KVM_TDX_TERMINATE_VM Adrian Hunter
2025-04-19 0:34 ` Vishal Annapurve
2025-04-19 1:08 ` Sean Christopherson [this message]
2025-04-22 7:30 ` Adrian Hunter
2025-04-19 1:12 ` Sean Christopherson
2025-04-22 8:13 ` Adrian Hunter
2025-04-22 9:37 ` Adrian Hunter
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=aAL3jRz3DTL8Ivhv@google.com \
--to=seanjc@google.com \
--cc=adrian.hunter@intel.com \
--cc=binbin.wu@linux.intel.com \
--cc=chao.gao@intel.com \
--cc=isaku.yamahata@intel.com \
--cc=kai.huang@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=reinette.chatre@intel.com \
--cc=rick.p.edgecombe@intel.com \
--cc=tony.lindgren@linux.intel.com \
--cc=vannapurve@google.com \
--cc=xiaoyao.li@intel.com \
--cc=yan.y.zhao@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox