Re: [RFC] KVM: Proposed uAPI for querying GSI and irqbypass status

[Marc Zyngier <maz@kernel.org>]

On Wed, 05 Aug 2026 09:26:56 +0100,
Mostafa Saleh <smostafa@google.com> wrote:
> 
> Hi Jing,
> 
> On Fri, Jul 31, 2026 at 10:26:26AM -0700, Jing Zhang wrote:

[drop the LLM generated stuff]

> > While interfaces in debugfs are fantastic for manual, retroactive
> > debugging on a developer workstation, they are not Dependable for
> > fleet-wide observability. This RFC aims to provide a proactive
> > monitoring solution that aligns KVM with production operational
> > requirements across architectures (both ARM and x86).
> > 
> > Would love to hear your thoughts on this perspective.
> 
> I agree that debugfs is not suitable for that purpose.
> 
> My main concerns are:
> 1- Why is /proc/interrupts not enough, it should show whether the
> interrupts are going through the host (not bypassed) and it should
> show when the host get a doorbell if the vCPU was not resident.

This.

Also, there is a very long standing ask to represent the output of
/proc/interrupts as a structured set, retrieved through a generic
kernel interface. I.e. *not* something KVM specific. Everybody asks,
nobody does. As usual.

And if you are interested in things being "Dependable for fleet-wide
observability" (I *love* the LLM-generated jargon), there is no way
you can make sense of what the guest sees without looking at the full
picture, i.e. the full machine.

> 2- Technical feasibility on arm64. Since the host does not have
> visibility into interrupts directly injected into the guest, it
> cannot accurately maintain the proposed counters vgic_its_vlpis_hw.

And GICv5 is going to make things even less observable, as only
doorbells fire on the host. My take is that for these, a PMU-type
interface is better suited.

But in general, a KVM-specific for something that is a system-wide
problem is IMO the wrong approach. You may want to put tglx in that
loop and see what he has to say.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.