Re: [PATCH] KVM: VMX: Postpone IPIv setup after successful vCPU creation

[Chao Gao <chao.gao@intel.com>]

On Thu, Jul 16, 2026 at 04:08:01PM +0000, Dmytro Maluka wrote:
>vCPU creation in kvm_vm_ioctl_create_vcpu() may fail after
>kvm_arch_vcpu_create() -> vmx_vcpu_create() already succeeded. In such
>case kvm_vm_ioctl_create_vcpu() destroys the newly created vCPU in the
>failure path. However, that leaves a side effect: the IPIv pid_table
>entry remains configured with this vCPU's pi_desc address. As a result,
>when another vCPU sends an IPI to the APIC ID of this failed-to-create
>vCPU, it will cause HW to write to this (freed!) pi_desc memory. [*]
>
>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.
>
>So instead fix the issue by moving the pid_table entry setup from
>.vcpu_create() to the newly introduced .vcpu_postcreate() callback
>called at the end of kvm_vm_ioctl_create_vcpu(), when we are sure that
>the vCPU creation succeeded.
>
>[*] Although, since this memory is freed into the kvm_vcpu_cache kmem
>    cache which is only used for allocating kvm_vcpus, _maybe_ this
>    memory will only be reused for pi_desc of another vCPU, not for
>    anything else. So _maybe_ this will only result in delivering the
>    IPI to a wrong vCPU (possibly of another VM) in the worst case, not
>    in a random corruption of kernel memory.
>
>Fixes: d588bb9be1da ("KVM: VMX: enable IPI virtualization")
>Signed-off-by: Dmytro Maluka <dmaluka@chromium.org>

Reviewed-by: Chao Gao <chao.gao@intel.com>