Re: [PATCH v3 03/16] KVM: VMX: Move posted interrupt delivery code to common header

[Paolo Bonzini <pbonzini@redhat.com>]

On 2/22/25 02:47, Binbin Wu wrote:
> From: Isaku Yamahata <isaku.yamahata@intel.com>
> 
> Move posted interrupt delivery code to common header so that TDX can
> leverage it.
> 
> No functional change intended.
> 
> Signed-off-by: Isaku Yamahata <isaku.yamahata@intel.com>
> [binbin: split into new patch]
> Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
> Reviewed-by: Chao Gao <chao.gao@intel.com>
> ---
> TDX interrupts v3:
>   - fixup comment and add Chao's Reviewed-by
>     https://lore.kernel.org/kvm/20250211025828.3072076-2-binbin.wu@linux.intel.com/T/#m990cab2280c2f5fdaffc22575c3e3e3012a691df
> 
> TDX interrupts v2:
> - Rebased due to moving pi_desc to vcpu_vt.
> 
> TDX interrupts v1:
> - This is split out from patch "KVM: TDX: Implement interrupt injection"
> ---
>   arch/x86/kvm/vmx/common.h | 68 +++++++++++++++++++++++++++++++++++++++
>   arch/x86/kvm/vmx/vmx.c    | 59 +--------------------------------
>   2 files changed, 69 insertions(+), 58 deletions(-)
> 
> diff --git a/arch/x86/kvm/vmx/common.h b/arch/x86/kvm/vmx/common.h
> index 9d4982694f06..8b12d8214b6c 100644
> --- a/arch/x86/kvm/vmx/common.h
> +++ b/arch/x86/kvm/vmx/common.h
> @@ -4,6 +4,7 @@
>   
>   #include <linux/kvm_host.h>
>   
> +#include "posted_intr.h"

This include is already needed in "KVM: VMX: Move common fields of 
struct vcpu_{vmx,tdx} to a struct" due to

+struct vcpu_vt {
+	/* Posted interrupt descriptor */
+	struct pi_desc pi_desc;

I'll fix it up in kvm-coco-queue.

Paolo

>   #include "mmu.h"
>   
>   union vmx_exit_reason {
> @@ -108,4 +109,71 @@ static inline int __vmx_handle_ept_violation(struct kvm_vcpu *vcpu, gpa_t gpa,
>   	return kvm_mmu_page_fault(vcpu, gpa, error_code, NULL, 0);
>   }
>   
> +static inline void kvm_vcpu_trigger_posted_interrupt(struct kvm_vcpu *vcpu,
> +						     int pi_vec)
> +{
> +#ifdef CONFIG_SMP
> +	if (vcpu->mode == IN_GUEST_MODE) {
> +		/*
> +		 * The vector of the virtual has already been set in the PIR.
> +		 * Send a notification event to deliver the virtual interrupt
> +		 * unless the vCPU is the currently running vCPU, i.e. the
> +		 * event is being sent from a fastpath VM-Exit handler, in
> +		 * which case the PIR will be synced to the vIRR before
> +		 * re-entering the guest.
> +		 *
> +		 * When the target is not the running vCPU, the following
> +		 * possibilities emerge:
> +		 *
> +		 * Case 1: vCPU stays in non-root mode. Sending a notification
> +		 * event posts the interrupt to the vCPU.
> +		 *
> +		 * Case 2: vCPU exits to root mode and is still runnable. The
> +		 * PIR will be synced to the vIRR before re-entering the guest.
> +		 * Sending a notification event is ok as the host IRQ handler
> +		 * will ignore the spurious event.
> +		 *
> +		 * Case 3: vCPU exits to root mode and is blocked. vcpu_block()
> +		 * has already synced PIR to vIRR and never blocks the vCPU if
> +		 * the vIRR is not empty. Therefore, a blocked vCPU here does
> +		 * not wait for any requested interrupts in PIR, and sending a
> +		 * notification event also results in a benign, spurious event.
> +		 */
> +
> +		if (vcpu != kvm_get_running_vcpu())
> +			__apic_send_IPI_mask(get_cpu_mask(vcpu->cpu), pi_vec);
> +		return;
> +	}
> +#endif
> +	/*
> +	 * The vCPU isn't in the guest; wake the vCPU in case it is blocking,
> +	 * otherwise do nothing as KVM will grab the highest priority pending
> +	 * IRQ via ->sync_pir_to_irr() in vcpu_enter_guest().
> +	 */
> +	kvm_vcpu_wake_up(vcpu);
> +}
> +
> +/*
> + * Post an interrupt to a vCPU's PIR and trigger the vCPU to process the
> + * interrupt if necessary.
> + */
> +static inline void __vmx_deliver_posted_interrupt(struct kvm_vcpu *vcpu,
> +						  struct pi_desc *pi_desc, int vector)
> +{
> +	if (pi_test_and_set_pir(vector, pi_desc))
> +		return;
> +
> +	/* If a previous notification has sent the IPI, nothing to do.  */
> +	if (pi_test_and_set_on(pi_desc))
> +		return;
> +
> +	/*
> +	 * The implied barrier in pi_test_and_set_on() pairs with the smp_mb_*()
> +	 * after setting vcpu->mode in vcpu_enter_guest(), thus the vCPU is
> +	 * guaranteed to see PID.ON=1 and sync the PIR to IRR if triggering a
> +	 * posted interrupt "fails" because vcpu->mode != IN_GUEST_MODE.
> +	 */
> +	kvm_vcpu_trigger_posted_interrupt(vcpu, POSTED_INTR_VECTOR);
> +}
> +
>   #endif /* __KVM_X86_VMX_COMMON_H */
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index 008e558a6f41..2d4185df1581 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -4186,50 +4186,6 @@ void vmx_msr_filter_changed(struct kvm_vcpu *vcpu)
>   		pt_update_intercept_for_msr(vcpu);
>   }
>   
> -static inline void kvm_vcpu_trigger_posted_interrupt(struct kvm_vcpu *vcpu,
> -						     int pi_vec)
> -{
> -#ifdef CONFIG_SMP
> -	if (vcpu->mode == IN_GUEST_MODE) {
> -		/*
> -		 * The vector of the virtual has already been set in the PIR.
> -		 * Send a notification event to deliver the virtual interrupt
> -		 * unless the vCPU is the currently running vCPU, i.e. the
> -		 * event is being sent from a fastpath VM-Exit handler, in
> -		 * which case the PIR will be synced to the vIRR before
> -		 * re-entering the guest.
> -		 *
> -		 * When the target is not the running vCPU, the following
> -		 * possibilities emerge:
> -		 *
> -		 * Case 1: vCPU stays in non-root mode. Sending a notification
> -		 * event posts the interrupt to the vCPU.
> -		 *
> -		 * Case 2: vCPU exits to root mode and is still runnable. The
> -		 * PIR will be synced to the vIRR before re-entering the guest.
> -		 * Sending a notification event is ok as the host IRQ handler
> -		 * will ignore the spurious event.
> -		 *
> -		 * Case 3: vCPU exits to root mode and is blocked. vcpu_block()
> -		 * has already synced PIR to vIRR and never blocks the vCPU if
> -		 * the vIRR is not empty. Therefore, a blocked vCPU here does
> -		 * not wait for any requested interrupts in PIR, and sending a
> -		 * notification event also results in a benign, spurious event.
> -		 */
> -
> -		if (vcpu != kvm_get_running_vcpu())
> -			__apic_send_IPI_mask(get_cpu_mask(vcpu->cpu), pi_vec);
> -		return;
> -	}
> -#endif
> -	/*
> -	 * The vCPU isn't in the guest; wake the vCPU in case it is blocking,
> -	 * otherwise do nothing as KVM will grab the highest priority pending
> -	 * IRQ via ->sync_pir_to_irr() in vcpu_enter_guest().
> -	 */
> -	kvm_vcpu_wake_up(vcpu);
> -}
> -
>   static int vmx_deliver_nested_posted_interrupt(struct kvm_vcpu *vcpu,
>   						int vector)
>   {
> @@ -4289,20 +4245,7 @@ static int vmx_deliver_posted_interrupt(struct kvm_vcpu *vcpu, int vector)
>   	if (!vcpu->arch.apic->apicv_active)
>   		return -1;
>   
> -	if (pi_test_and_set_pir(vector, &vt->pi_desc))
> -		return 0;
> -
> -	/* If a previous notification has sent the IPI, nothing to do.  */
> -	if (pi_test_and_set_on(&vt->pi_desc))
> -		return 0;
> -
> -	/*
> -	 * The implied barrier in pi_test_and_set_on() pairs with the smp_mb_*()
> -	 * after setting vcpu->mode in vcpu_enter_guest(), thus the vCPU is
> -	 * guaranteed to see PID.ON=1 and sync the PIR to IRR if triggering a
> -	 * posted interrupt "fails" because vcpu->mode != IN_GUEST_MODE.
> -	 */
> -	kvm_vcpu_trigger_posted_interrupt(vcpu, POSTED_INTR_VECTOR);
> +	__vmx_deliver_posted_interrupt(vcpu, &vt->pi_desc, vector);
>   	return 0;
>   }
>