Received-SPF: pass (google.com: domain of linux-kernel+bounces-147381-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Tue, 16 Apr 2024 11:25:20 -0700
In-Reply-To: <b7177278-2a39-4fe6-9690-573b70e2ed0e@oracle.com>
Precedence: bulk
Mime-Version: 1.0
References: <20240215160136.1256084-1-alejandro.j.jimenez@oracle.com>
 <20240215160136.1256084-3-alejandro.j.jimenez@oracle.com> <56130d48-706f-d1d0-bd23-69544298f353@oracle.com>
 <b7177278-2a39-4fe6-9690-573b70e2ed0e@oracle.com>
Message-ID: <Zh7CkBHFXES9HeIL@google.com>
Subject: Re: [RFC 2/3] x86: KVM: stats: Add stat counter for IRQs injected via APICv
From: Sean Christopherson <seanjc@google.com>
To: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
Cc: Dongli Zhang <dongli.zhang@oracle.com>, kvm@vger.kernel.org, pbonzini@redhat.com, 
	linux-kernel@vger.kernel.org, joao.m.martins@oracle.com, 
	boris.ostrovsky@oracle.com, mark.kanda@oracle.com, 
	suravee.suthikulpanit@amd.com, mlevitsk@redhat.com
Content-Type: text/plain; charset="us-ascii"

On Thu, Feb 15, 2024, Alejandro Jimenez wrote:
> Hi Dongli
> 
> On 2/15/24 11:16, Dongli Zhang wrote:
> > Hi Alejandro,
> > 
> > Is there any use case of this counter in the bug?
> 
> I don't have a specific bug in mind that this is trying to address.  This
> patch is just an example is to show how existing data points (i.e. the
> trace_kvm_apicv_accept_irq tracepoint) can also be exposed via the stats
> framework with minimal overhead, and to support the point in the cover letter
> that querying the binary stats could be the best choice for a "single source"
> that tells us the full status of APICv/AVIC (i.e. is SVM and IOMMU AVIC both
> working, are there any inhibits set, etc)

Yeah, but as noted in my response to the cover letter, stats are ABI, whereas
tracepoints are not, i.e. the bar for adding stats is much higher than the bar
for adding tracepoints.

In other words, stats need to come with a concrete use case (preferably more than
one), an explanation of why userspace needs a KVM-provided stat, and a decent
level of confidence that KVM can provide deterministic, sane, and broadly useful
data.

E.g. this proposed stat is of limited usefulness because it applies to a very
narrow combination of IRQs and hardware.