[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4b81af0a-559e-b8f5-ab8a-167c88fec2d5@redhat.com>
Date: Thu, 21 Oct 2021 21:43:31 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Sean Christopherson <seanjc@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
x86@...nel.org
Cc: "H. Peter Anvin" <hpa@...or.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org
Subject: Re: [PATCH 4/4] KVM: VMX: Register posted interrupt wakeup handler
iff APICv is enabled
On 09/10/21 02:11, Sean Christopherson wrote:
> Don't bother registering a posted interrupt wakeup handler if APICv is
> disabled, KVM utilizes the wakeup vector if and only if APICv is enabled.
> Practically speaking, there's no meaningful functional change as KVM's
> wakeup handler is a glorified nop if there are no vCPUs using posted
> interrupts, not to mention that nothing in the system should be sending
> wakeup interrupts when APICv is disabled.
>
> Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> ---
> arch/x86/kvm/vmx/vmx.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index 9164f1870d49..df9ad4675215 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -7553,7 +7553,8 @@ static void vmx_migrate_timers(struct kvm_vcpu *vcpu)
>
> static void hardware_unsetup(void)
> {
> - kvm_unregister_posted_intr_wakeup_handler(pi_wakeup_handler);
> + if (enable_apicv)
> + kvm_unregister_posted_intr_wakeup_handler(pi_wakeup_handler);
>
> if (nested)
> nested_vmx_hardware_unsetup();
> @@ -7907,7 +7908,8 @@ static __init int hardware_setup(void)
> if (r)
> nested_vmx_hardware_unsetup();
>
> - kvm_register_posted_intr_wakeup_handler(pi_wakeup_handler);
> + if (enable_apicv)
> + kvm_register_posted_intr_wakeup_handler(pi_wakeup_handler);
>
> return r;
> }
Also adds unnecessary complexity (you have to ensure the condition
cannot change from one call to the other), so I am only queuing patches
1 and 2.
Paolo
Powered by blists - more mailing lists