[RFC PATCH v6 03/35] KVM: arm64: Add CONFIG_KVM_ARM_SPE Kconfig option

[Alexandru Elisei]

Hi James,

On Mon, Jan 12, 2026 at 12:09:19PM +0000, James Clark wrote:
> 
> 
> On 12/01/2026 11:26 am, Alexandru Elisei wrote:
> > Hi James,
> > 
> > On Fri, Jan 09, 2026 at 04:29:50PM +0000, James Clark wrote:
> > > 
> > > 
> > > On 14/11/2025 4:06 pm, Alexandru Elisei wrote:
> > > > Add a new configuration option that will be used for KVM SPE emulation.
> > > > CONFIG_KVM_ARM_SPE depends on the SPE driver being builtin because:
> > > > 
> > > > 1. The SPE driver maintains a cpumask of physical CPUs that support SPE,
> > > >      and that will be used by KVM to emulate SPE on heterogeneous systems.
> > > > 
> > > > 2. KVM will rely on the SPE driver enabling the SPE interrupt at the GIC
> > > >      level.
> > > > 
> > > > Signed-off-by: Alexandru Elisei <alexandru.elisei at arm.com>
> > > > ---
> > > >    arch/arm64/kvm/Kconfig | 8 ++++++++
> > > >    1 file changed, 8 insertions(+)
> > > > 
> > > > diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
> > > > index 4f803fd1c99a..31388b5b2655 100644
> > > > --- a/arch/arm64/kvm/Kconfig
> > > > +++ b/arch/arm64/kvm/Kconfig
> > > > @@ -83,4 +83,12 @@ config PTDUMP_STAGE2_DEBUGFS
> > > >    	  If in doubt, say N.
> > > > +config KVM_ARM_SPE
> > > > +	bool
> > > > +	depends on KVM && ARM_SPE_PMU=y
> > > 
> > > I think the most common configuration is module, so requiring built-in isn't
> > > great. If there's any way of avoiding it, even if it costs a little bit of
> > > pain, it would be good for adoption.
> > 
> > I'm not sure how that could be done. You need the buffer maintenance interrupt
> > to do a VM exit so KVM can inject the virtual interrupt back into the guest,
> > otherwise there's a possibility of a large blackout window when the buffer is
> > full.
> 
> Without expanding more I don't see how injecting an interrupt is strongly
> related to the way it's compiled.

It's the SPE driver that enables the hardware interrupt in the GIC.

> 
> > 
> > The code also relies on the SPE driver to probe all the SPUs in the system.
> > 
> 
> I don't think that's a hard requirement either, the KVM code could fairly
> easily do this itself. Inline the common code and put it in a shared header
> etc. I'm sure there are lots of creative ways to flip the dependencies that
> might not be "proper" software engineering. But like I said a bit of pain
> here might be beneficial overall.

Userspace gets the maximum buffer size and the SPE instance id from the sysfs
files.

So KVM would have to parse the DTB, read PMBIDR_EL1 and PMSIDR_EL1 on each
physical CPU in the system, create the sysfs files (at least 'type', 'cpumask'
and 'max_buffer_size' or whatever that ends up being named) and install a dummy
IRQ handler before the SPE driver is loaded.

Then when the SPE driver is loaded, the driver would have to remove the IRQ
handler and install its own, and create the rest of the sysfs files.

That's assuming that the SPE driver is loaded after KVM. I think it's possible
for the SPE driver to be loaded first. So both KVM and SPE would have be able to
communicate with one other in case the other probed first.

Is having to change the symbol ARM_SPE_PMU from 'm' to 'y' worth this? I am not
convinced and I don't see much use for going down this rabbit hole at this stage
of the series.

Also, since KVM would partially populate the sysfs directory for each SPE
instance, would it be reasonable for software to assume that the SPE driver is
loaded based on this and start using it? For example, how does perf detect the
presence of the arm_spe event?

Thanks,
Alex