| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <052c37b5-8deb-413e-b8cf-966e00f608ef@redhat.com>
Date: Wed, 12 Mar 2025 19:39:20 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Binbin Wu <binbin.wu@...ux.intel.com>, seanjc@...gle.com,
kvm@...r.kernel.org
Cc: rick.p.edgecombe@...el.com, kai.huang@...el.com, adrian.hunter@...el.com,
reinette.chatre@...el.com, xiaoyao.li@...el.com, tony.lindgren@...el.com,
isaku.yamahata@...el.com, yan.y.zhao@...el.com, chao.gao@...el.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 03/16] KVM: VMX: Move posted interrupt delivery code to
common header
On 2/22/25 02:47, Binbin Wu wrote:
> From: Isaku Yamahata <isaku.yamahata@...el.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@...el.com>
> [binbin: split into new patch]
> Signed-off-by: Binbin Wu <binbin.wu@...ux.intel.com>
> Reviewed-by: Chao Gao <chao.gao@...el.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;
> }
>
Powered by blists - more mailing lists