Re: [PATCH v4 08/15] KVM: x86: Deactivate APICv on vCPU with APIC disabled

[Maxim Levitsky]

On Sat, 2022-05-07 at 21:39 -0500, Suravee Suthikulpanit wrote:
> APICv should be deactivated on vCPU that has APIC disabled.
> Therefore, call kvm_vcpu_update_apicv() when changing
> APIC mode, and add additional check for APIC disable mode
> when determine APICV activation,
> 
> Suggested-by: Maxim Levitsky <mlevitsk@xxxxxxxxxx>
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
> ---
>  arch/x86/kvm/lapic.c | 4 +++-
>  arch/x86/kvm/x86.c   | 4 +++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 8b8c4a905976..680824d7aa0d 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -2346,8 +2346,10 @@ void kvm_lapic_set_base(struct kvm_vcpu *vcpu, u64 value)
>  	if (((old_value ^ value) & X2APIC_ENABLE) && (value & X2APIC_ENABLE))
>  		kvm_apic_set_x2apic_id(apic, vcpu->vcpu_id);
>  
> -	if ((old_value ^ value) & (MSR_IA32_APICBASE_ENABLE | X2APIC_ENABLE))
> +	if ((old_value ^ value) & (MSR_IA32_APICBASE_ENABLE | X2APIC_ENABLE)) {
> +		kvm_vcpu_update_apicv(vcpu);
>  		static_call_cond(kvm_x86_set_virtual_apic_mode)(vcpu);

As futher optimization, we might even get rid of .set_virtual_apic_mode
and do all of this in kvm_vcpu_update_apicv.
But no need to do this now.


> +	}
>  
>  	apic->base_address = apic->vcpu->arch.apic_base &
>  			     MSR_IA32_APICBASE_BASE;
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 8ee8c91fa762..77e49892dea1 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -9836,7 +9836,9 @@ void kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu)
>  
>  	down_read(&vcpu->kvm->arch.apicv_update_lock);
>  
> -	activate = kvm_vcpu_apicv_activated(vcpu);
> +	/* Do not activate APICV when APIC is disabled */
> +	activate = kvm_vcpu_apicv_activated(vcpu) &&
> +		   (kvm_get_apic_mode(vcpu) != LAPIC_MODE_DISABLED);
>  
>  	if (vcpu->arch.apicv_active == activate)
>  		goto out;

Looks very good!

Reviewed-by: Maxim Levitsky <mlevitsk@xxxxxxxxxx>

Best regards,
	Maxim Levitsky