Received-SPF: pass (google.com: domain of linux-kernel+bounces-199865-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Mon, 3 Jun 2024 17:16:31 -0700
In-Reply-To: <20240429155738.990025-2-alejandro.j.jimenez@oracle.com>
Precedence: bulk
Mime-Version: 1.0
References: <20240429155738.990025-1-alejandro.j.jimenez@oracle.com> <20240429155738.990025-2-alejandro.j.jimenez@oracle.com>
Message-ID: <Zl5c3-k0-a7Vvlo5@google.com>
Subject: Re: [PATCH 1/4] KVM: x86: Expose per-vCPU APICv status
From: Sean Christopherson <seanjc@google.com>
To: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com, linux-kernel@vger.kernel.org, 
	suravee.suthikulpanit@amd.com, vashegde@amd.com, mlevitsk@redhat.com, 
	joao.m.martins@oracle.com, boris.ostrovsky@oracle.com, mark.kanda@oracle.com
Content-Type: text/plain; charset="us-ascii"

On Mon, Apr 29, 2024, Alejandro Jimenez wrote:
> Expose the APICv activation status of individual vCPUs via the stats
> subsystem. In special cases a vCPU's APICv can be deactivated/disabled
> even though there are no VM-wide inhibition reasons. The only current
> example of this is AVIC for a vCPU running in nested mode. This type of
> inhibition is not recorded in the VM inhibit reasons or visible in
> current tracepoints.
> 
> Signed-off-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
> ---
>  arch/x86/include/asm/kvm_host.h | 1 +
>  arch/x86/kvm/lapic.c            | 1 +
>  arch/x86/kvm/x86.c              | 2 ++
>  3 files changed, 4 insertions(+)
> 
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 1d13e3cd1dc5..12f30cb5c842 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -1573,6 +1573,7 @@ struct kvm_vcpu_stat {
>  	u64 preemption_other;
>  	u64 guest_mode;
>  	u64 notify_window_exits;
> +	u64 apicv_active;

Hrm, do we really have no way to effectively symlink stats to internal state?
That seems like a flaw.  It's obviously not the end of the world, but having to
burn 8 bytes per vCPU for boolean stats that are 1:1 reflections of KVM state is
going to be a deterrent for future stats.

>  };
>  
>  struct x86_instruction_info;
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index cf37586f0466..37fe75a5db8c 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -2872,6 +2872,7 @@ int kvm_create_lapic(struct kvm_vcpu *vcpu, int timer_advance_ns)
>  	 */
>  	if (enable_apicv) {
>  		apic->apicv_active = true;
> +		vcpu->stat.apicv_active = apic->apicv_active;
>  		kvm_make_request(KVM_REQ_APICV_UPDATE, vcpu);
>  	}
>  
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index e9ef1fa4b90b..0451c4c8d731 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -304,6 +304,7 @@ const struct _kvm_stats_desc kvm_vcpu_stats_desc[] = {
>  	STATS_DESC_COUNTER(VCPU, preemption_other),
>  	STATS_DESC_IBOOLEAN(VCPU, guest_mode),
>  	STATS_DESC_COUNTER(VCPU, notify_window_exits),
> +	STATS_DESC_IBOOLEAN(VCPU, apicv_active),
>  };
>  
>  const struct kvm_stats_header kvm_vcpu_stats_header = {
> @@ -10625,6 +10626,7 @@ void __kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu)
>  		goto out;
>  
>  	apic->apicv_active = activate;
> +	vcpu->stat.apicv_active = apic->apicv_active;
>  	kvm_apic_update_apicv(vcpu);
>  	static_call(kvm_x86_refresh_apicv_exec_ctrl)(vcpu);
>  
> -- 
> 2.39.3
>