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

[James Clark]

On 12/01/2026 12:09 pm, 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.
> 
>>
>> 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.
> 
>>>
>>> It was basically the first thing I got stuck on trying to get it to 
>>> work. Or
>>> if it really can't be done, maybe some kind of debug message to say why
>>> enabling failed.
>>
>> When you search for the symbol in menuconfig you get a list of the 
>> symbols it
>> depends on.

Also, it wasn't easy for me to find this either. I had to read the code 
and debug it. I find it hard to believe that other people won't get 
stuck here without a warning. It will be "I've got SPE, I've got KVM but 
it's just not working and there's no warning".

> 
> Right, but that doesn't address the problems of adoption at all.
> 
> Having it on by default when SPE and KVM are already enabled in their 
> default configs is the difference between people being able to use this 
> with zero friction vs 200 people all getting stuck and then coming to 
> ask me why it's not working and distros having to update SPE from being 
> a module to static.
> 
>>
>> Thanks,
>> Alex
> 
>