[PATCH 11/32] KVM: arm64: gic-v5: Trap and emulate ICH_PPI_HMRx_EL1 accesses

[Marc Zyngier]

On Tue, 16 Dec 2025 11:54:59 +0000,
Sascha Bischoff <Sascha.Bischoff at arm.com> wrote:
> 
> On Tue, 2025-12-16 at 10:41 +0000, Marc Zyngier wrote:
> > On Fri, 12 Dec 2025 15:22:39 +0000,
> > Sascha Bischoff <Sascha.Bischoff at arm.com> wrote:
> > > 
> > > The ICC_PPI_HMRx_EL1 register is used to determine which PPIs use
> > > Level-sensitive semantics, and which use Edge. For a GICv5 guest,
> > > the
> > > correct view of the virtual PPIs must be provided to the guest.
> > 
> > s/ICH/ICC/ in $SUBJECT
> > 
> > > 
> > > The GICv5 architecture doesn't provide an ICV_PPI_HMRx_EL1 or
> > 
> > The spec disagree with you here (see 9.5.4).
> > 
> > > ICH_PPI_HMRx_EL2 register, and therefore all guest accesses must be
> > > trapped to avoid the guest directly accessing the host's
> > > ICC_PPI_HMRx_EL1 state. This change hence configures the FGTs to
> > > always trap and emulate guest accesses to the HMR running a
> > > GICv5-based guest.
> > 
> > The real question is what we gain by emulating this register, given
> > that virtual PPIs are only guaranteed to exist if the physical
> > version
> > exist. If they exist, then the handling mode is defined by the
> > that HW, and we can't deviate from it.
> > 
> > Given that, I can't really see the point in trapping something that
> > is
> > bound to be the same thing as the host, unless this comes with
> > additional restrictions, for example a mask of interrupts that are
> > actually exposed to the guest.
> > 
> > Or am I missing something?
> 
> No, I think you're quite correct, and this doesn't add meaningful
> value.
> 
> This all stems from my misunderstanding that GICv5 vPPIs are
> independent from the physical PPIs. This is not the case, however, as
> the set of implemented virtual PPIs matches the physically implemented
> PPIs. The handling mode for each PPI will be reflected in the
> ICC/ICV_PPI_HMRx_EL1 sysregs.
> 
> This actually has wider impacts:
> 
>    1. It makes sense to drop this commit altogether.
>    
>    2. When initialising the GICv5 PPIs ("KVM: arm64: gic-v5: Init
>    Private IRQs (PPIs) for GICv5"), we skip setting their config
>    (LEVEL/EDGE).
>    
>    3. In vgic_v5_reset ("KVM: arm64: gic-v5: Reset vcpu state"), sync
>    the host's PPI HMR state (ICC_PPI_HMRx_EL1) to KVM's vPPI shadow
>    state as the virtual PPIs should match that, and we need that to
>    correctly handle SW-driven PPI injection. Currently, this code
>    actually calculates the HMR contents for trapping and emulating,
>    which again can be dropped altogether.
>    
>    4. vgic_hmr can be dropped from the vgic_v5 CPUIF too.
> 
> Does this sound reasonable to you?

It does, to some extent. The one thing I have been thinking about is
how to hide PPIs that are implemented by the host, but not exposed to
the guest.

For that, I think we need a mask of PPIs that the kernel deals with
(timers, PMU, SPE one day), and use it to sanitise the HMR. For that,
we still need to trap these registers.

But it then begs the question: what does it mean for userspace
injection of PPIs? Do we still allow it? How does userspace discover
the implemented PPIs? How does userspace tells us *in advance* about
that so that we can affect the above mask?

At this stage, I'm tempted to say "screw that, userspace doesn't get
to touch PPIs -- at least not for now".

Thoughts?

	M.

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