[PATCH 04/43] irqchip/gic-v5: Provide IRS config frame attrs to KVM

Sascha Bischoff Sascha.Bischoff at arm.com
Fri May 1 09:46:58 PDT 2026


On Tue, 2026-04-28 at 15:56 +0100, Marc Zyngier wrote:
> On Mon, 27 Apr 2026 17:07:24 +0100,
> Sascha Bischoff <Sascha.Bischoff at arm.com> wrote:
> > 
> > KVM needs to interact with the host IRS in order to, for example,
> > make
> > VMs or VPEs valid. There are two potential approaches here. Either
> > the
> > host irqchip driver can provide an interface, or KVM can interact
> > directly with the host IRS. The latter of these two is chosen as
> > the
> > set of MMIO registers that KVM needs to interact with is orthogonal
> > to
> > the set used by the host irqchip driver (with the exception of some
> > of
> > the read-only IRS_IDRx registers).
> > 
> > Pass KVM a pointer to an IRS config frame - the config frame
> > belonging
> > to ANY IRS is fine as long as one IRS's config frame is used
> > consistently - in struct gic_kvm_info. Additionally, include a flag
> > telling KVM whether the IRS is coherent or non-coherent in order to
> > make sure that KVM can do the correct cache state management, if
> > required.
> > 
> > Signed-off-by: Sascha Bischoff <sascha.bischoff at arm.com>
> > ---
> >  drivers/irqchip/irq-gic-v5-irs.c      | 26
> > ++++++++++++++++++++++++++
> >  drivers/irqchip/irq-gic-v5.c          |  3 +++
> >  include/linux/irqchip/arm-gic-v5.h    |  2 ++
> >  include/linux/irqchip/arm-vgic-info.h |  5 +++++
> >  4 files changed, 36 insertions(+)
> > 
> > diff --git a/drivers/irqchip/irq-gic-v5-irs.c
> > b/drivers/irqchip/irq-gic-v5-irs.c
> > index f3fce0b1e25d9..5dfa043cf9e34 100644
> > --- a/drivers/irqchip/irq-gic-v5-irs.c
> > +++ b/drivers/irqchip/irq-gic-v5-irs.c
> > @@ -50,6 +50,32 @@ static void irs_writeq_relaxed(struct
> > gicv5_irs_chip_data *irs_data,
> >  	writeq_relaxed(val, irs_data->irs_base + reg_offset);
> >  }
> >  
> > +void __iomem *gicv5_irs_get_config_frame_base(void)
> > +{
> > +	struct gicv5_irs_chip_data *irs_data =
> > per_cpu(per_cpu_irs_data,
> > +						      
> > smp_processor_id());
> > +
> > +	if (!irs_data)
> > +		return NULL;
> > +
> > +	return irs_data->irs_base;
> > +}
> > +
> > +bool gicv5_irs_is_non_coherent(void)
> > +{
> > +	struct gicv5_irs_chip_data *irs_data =
> > per_cpu(per_cpu_irs_data,
> > +						      
> > smp_processor_id());
> > +
> > +	if (!irs_data) {
> > +		pr_err("Failed to look up IRS for CPU %d\n",
> > +		       smp_processor_id());
> > +		return false;
> > +	}
> > +
> > +	return !!(irs_data->flags & IRS_FLAGS_NON_COHERENT);
> > +}
> > +
> 
> Frankly, we don't need these micro-helpers. Just add *one* that
> returns a pointer to the IRS data for CPU0, and do the information
> cherry-picking in the caller.

I've dropped these and have done what you suggested.

> 
> > +
> >  /*
> >   * The polling wait (in gicv5_wait_for_op_s_atomic()) on a GIC
> > register
> >   * provides the memory barriers (through MMIO accessors)
> > diff --git a/drivers/irqchip/irq-gic-v5.c b/drivers/irqchip/irq-
> > gic-v5.c
> > index 58e457d4c1476..3329019722360 100644
> > --- a/drivers/irqchip/irq-gic-v5.c
> > +++ b/drivers/irqchip/irq-gic-v5.c
> > @@ -1134,6 +1134,9 @@ static void __init
> > gic_of_setup_kvm_info(struct device_node *node)
> >  
> >  	gic_v5_kvm_info.type = GIC_V5;
> >  
> > +	gic_v5_kvm_info.gicv5_irs.base =
> > gicv5_irs_get_config_frame_base();
> > +	gic_v5_kvm_info.gicv5_irs.non_coherent =
> > gicv5_irs_is_non_coherent();
> > +
> >  	/* GIC Virtual CPU interface maintenance interrupt */
> >  	gic_v5_kvm_info.no_maint_irq_mask = false;
> >  	gic_v5_kvm_info.maint_irq = irq_of_parse_and_map(node, 0);
> 
> While you're at it, you may want to fix the check on the maintenance
> interrupt, which gives up registering with KVM if no MI is found,
> even
> in the absence of FEAT_GCIE_LEGACY.

I've done the re-work here. GICv5 systems without FEAT_GCIE_LEGACY can
now omit the MI. If we have the feature, then the MI remains mandatory,
and we bail out at probe-time in kvm_vgic_hyp_init(). Will include this
in my next version of the series.

> 
> Thanks,
> 
> 	M.
> 



More information about the linux-arm-kernel mailing list