From: "Huang, Kai" <kai.huang@intel.com>
To: "dmaluka@chromium.org" <dmaluka@chromium.org>,
"seanjc@google.com" <seanjc@google.com>
Cc: "Gao, Chao" <chao.gao@intel.com>,
"aashish@aashishsharma.net" <aashish@aashishsharma.net>,
"guang.zeng@intel.com" <guang.zeng@intel.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"vineeth@bitbyteword.org" <vineeth@bitbyteword.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jaszczyk@chromium.org" <jaszczyk@chromium.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"Dong, Chuanxiao" <chuanxiao.dong@intel.com>
Subject: Re: [PATCH] KVM: VMX: Postpone IPIv setup after successful vCPU creation
Date: Fri, 17 Jul 2026 12:59:38 +0000 [thread overview]
Message-ID: <792366b7d918faca3f40bccab56bab965e7e34f5.camel@intel.com> (raw)
In-Reply-To: <20260716160801.3155582-1-dmaluka@chromium.org>
>
> An easy fix would be to clear the pid_table entry in vmx_vcpu_free().
> However that would be still problematic, for the following reason:
> userspace may try to create a vCPU with the same vcpu_id as an existing
> one; vmx_vcpu_create() will succeed, and only after that
> kvm_vm_ioctl_create_vcpu() will check for the duplicate vcpu_id and
> fail with -EEXIST and then free the vCPU in the failure path. So in this
> failure path, vmx_vcpu_free() would clear the pid_table entry for that
> already existing good vCPU, i.e. effectively disable IPIv for that vCPU.
IMHO this seems a bit fragile? If something similar to pid_table coming up in
the future, we could end up with a similar problem.
The "duplicated vcpu_id check" seems the ones that should happen as early as
possible. Is it better to move the "duplicated vcpu_id check" earlier before
vmx_vcpu_create(), e.g., even before the kvm_arch_vcpu_precreate()? In this
case we can do the pid_table cleanup in vmx_vcpu_free() I think.
The downside is this is common KVM code change for all archs, but it doesn't
seem this will bring problem to other archs.
next prev parent reply other threads:[~2026-07-17 12:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 16:08 Dmytro Maluka
2026-07-17 12:59 ` Huang, Kai [this message]
2026-07-17 16:20 ` Dmytro Maluka
2026-07-17 21:21 ` Huang, Kai
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=792366b7d918faca3f40bccab56bab965e7e34f5.camel@intel.com \
--to=kai.huang@intel.com \
--cc=aashish@aashishsharma.net \
--cc=chao.gao@intel.com \
--cc=chuanxiao.dong@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dmaluka@chromium.org \
--cc=guang.zeng@intel.com \
--cc=jaszczyk@chromium.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=vineeth@bitbyteword.org \
/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