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

[James Clark]

On 13/01/2026 10:25 am, Alexandru Elisei wrote:
> Hi James,
> 
> On Mon, Jan 12, 2026 at 03:18:53PM +0000, Alexandru Elisei wrote:
>> 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.

No, definitely not something that needs to be done at this point.

>>
>> 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?
> 
> Coming back to this, I do understand and agree with your concerns, so after
> talking in private I came up with exporting the symbol kvm_host_spe_init() -
> that's the function which adds the SPE instance to the list of SPUs.
> 
> With this change the SPE driver can be built as a module, but SPE for a VM is
> available only as long as the driver is loaded.
> 
> I hope that improves the adoption story :)
> 
> Thanks,
> Alex

Nice, if it's not too horrible we should try it. If it turns out to be 
horrible then yes we'll have to ask people to change their configs.