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

Sean Christopherson <[email protected]>
Newsgroups org.kernel.vger.kvm,dev.linux.lists.kvmarm
Message-ID <[email protected]>
On Wed, Aug 05, 2026, Marc Zyngier wrote:
> On Wed, 05 Aug 2026 09:26:56 +0100,
> Mostafa Saleh <[email protected]> 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.

+1 to not making this level of detail KVM specific.  Ideally, I'd want more than
what /proc/interrupts offers, e.g. it'd be nice to capture what "mode" an IRQ is
configured for (normal/remapped, IRQ bypass, x86's posted MSI, etc.).  But that's
an argument for extending /proc/irq and/or providing structured output of _that_,
not for throwing something into KVM.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.