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

[Mostafa Saleh <smostafa@google.com>]

Hi Jing,

On Fri, Jul 31, 2026 at 10:26:26AM -0700, Jing Zhang wrote:
> On Tue, Jul 28, 2026 at 2:45 AM Mostafa Saleh <smostafa@google.com> wrote:
> >
> > Hi Jing,
> >
> > On Fri, Jul 17, 2026 at 09:26:57AM -0700, Jing Zhang wrote:
> > > This RFC proposes a new KVM uAPI to allow a VMM to programmatically
> > > query the status of a GSI, with a particular focus on determining
> > > the success or failure of Irqbypass.
> > >
> > >
> > > 1. Motivation
> > >
> > > The primary motivation for this uAPI is to bridge the operational gap

[...]

> > > /* The irqbypass path is fully enabled and active in hardware */
> > > #define KVM_GSI_STATE_FLAG_BYPASS_ACTIVE   (1 << 2)
> > >
> > > /* Example architecture-specific failure reasons for ARM64 */
> > > #define KVM_ARM_GSI_FAILURE_REASON_NONE             0
> > > #define KVM_ARM_GSI_FAILURE_REASON_NO_ITS           1 /* No ITS/GICv4 support */
> > > #define KVM_ARM_GSI_FAILURE_REASON_NO_MSI_ADDR      2 /* MSI address unset */
> > > #define KVM_ARM_GSI_FAILURE_REASON_GIC_HW_REJECT    3 /* GIC rejected map */
> > > #define KVM_ARM_GSI_FAILURE_REASON_INVALID_STATE    4 /* Guest state block */
> > >
> > > struct kvm_gsi_state {
> > >     __u32 gsi;              /* IN: The GSI to query */
> > >     __u32 flags;            /* OUT: High-level status flags */
> > >     __u64 counter_success;  /* OUT: Generic counter for successful bypass */
> >
> > I do not think that is possible on arm64, the host does not know
> > about the interrupts directly injected to the guest, so it can not
> > maitain such a counter.
> >
> > Thanks,
> > Mostafa
> >
> 
> Hi Mostafa,
> 
> Thank you for taking the time to review this RFC and for your valuable feedback.
> 
> To clarify the primary motivation here: the goal of this new uAPI is
> to enable programmatic, stable, and fine-grained monitoring of
> interrupt bypass status in production environments, where existing
> mechanisms like debugfs are simply not viable.
> 
> Here are a few key reasons why we believe a dedicated uAPI/ioctl is
> necessary rather than relying on debugfs:
> 1. Production Hardening and Access Restrictions: In many hardened
> production or cloud environments, debugfs is completely disabled
> (CONFIG_DEBUG_FS=n), unmounted, or heavily restricted due to security
> and performance overhead concerns. Relying on it means the Virtual
> Machine Monitor (VMM) loses all visibility into interrupt performance
> regressions in the very environment where monitoring matters most.
> 2. Lack of ABI Stability: As you know, debugfs makes no ABI stability
> guarantees. Its output format can change between kernel versions
> without notice. Basing production monitoring and telemetry pipelines
> on scraping debugfs is fragile and prone to breaking during kernel
> upgrades.
> 3. Programmatic Efficiency: Scraping and parsing text files from
> userspace is inefficient for high-frequency or fleet-wide monitoring.
> A binary ioctl interface (KVM_GET_GSI_STATE) provides a lightweight,
> deterministic, and highly scalable way for the VMM to query state on
> demand.
> 4. Marrying Topology with Live State: KVM holds the runtime status of
> the bypass, but only userspace (the VMM) understands the full topology
> (i.e., which GSI belongs to which passthrough device). This uAPI
> allows the VMM to programmatically marry its topological knowledge
> with KVM's live execution state without relying on side-band manual
> debugging tools.
> 
> 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.

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.

Thanks,
Mostafa

> 
> Thanks,
> Jing