RFC mostly because the kernel support is not yet upsteam.
This is based on

https://lore.kernel.org/linux-arm-kernel/20251223-kvm-arm64-sme-v9-0-8be3867cb883@kernel.org/

Properly testing this will take more time.  I'm not 100%
sure how to confirm that the SME registers have the correct
value across migration.

I'm thinking of a test case in which the ZArray is loaded,
the test program pauses, migration or vm save/load initiated,
and the ZArray contents are verified after continuing.
But anything that takes timing into account like that
seems way sketchy, so I dunno.

All I can say at the moment is that the VM does start up
with SME enabled and stuff doesn't crash, but that the
get/put paths are not really exercised.


r~


Richard Henderson (13):
  NOTFORMERGE: Update linux-headers for arm64 kvm from SME devel branch
  target/arm: Remove aarch64 test for kvm
  target/arm: Move kvm_arm_sve_get_vls within kvm.c
  target/arm: Init sve_vq in kvm_arm_set_cpu_features_from_host
  target/arm: Move kvm test out of cpu_arm_set_sve
  target/arm: Drop kvm_arm_sve_supported
  target/arm: Remove kvm test in arm_set_pmu
  target/arm: Drop kvm_arm_pmu_supported
  target/arm: Detect SME in kvm_arm_get_host_cpu_features
  target/arm: Add vq argument to kvm_arch_{get,put}_sve
  target/arm: Add have_ffr argument to kvm_arch_{get,put}_sve
  target/arm: Add SME state to kvm_arch_{get,put}_registers
  target/arm: Add SME properties for KVM

 linux-headers/asm-arm64/kvm.h |  33 ++++
 linux-headers/linux/kvm.h     |   1 +
 target/arm/kvm_arm.h          |  35 ----
 target/arm/cpu.c              |   4 -
 target/arm/cpu64.c            |  90 ++++++----
 target/arm/kvm-stub.c         |  15 --
 target/arm/kvm.c              | 308 +++++++++++++++++++++++-----------
 target/arm/tcg/cpu64.c        |   2 +-
 8 files changed, 306 insertions(+), 182 deletions(-)

-- 
2.43.0

On Mon, 16 Feb 2026 at 03:45, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> RFC mostly because the kernel support is not yet upsteam.
> This is based on
>
> https://lore.kernel.org/linux-arm-kernel/20251223-kvm-arm64-sme-v9-0-8be3867cb883@kernel.org/
>
> Properly testing this will take more time.  I'm not 100%
> sure how to confirm that the SME registers have the correct
> value across migration.

Am I right that patches 2-8 in here:

>   target/arm: Remove aarch64 test for kvm
>   target/arm: Move kvm_arm_sve_get_vls within kvm.c
>   target/arm: Init sve_vq in kvm_arm_set_cpu_features_from_host
>   target/arm: Move kvm test out of cpu_arm_set_sve
>   target/arm: Drop kvm_arm_sve_supported
>   target/arm: Remove kvm test in arm_set_pmu
>   target/arm: Drop kvm_arm_pmu_supported

are preparatory cleanups that don't depend on the new
linux-headers changes?

(also maybe 10 and 11)

thanks
-- PMM

On 2/25/26 04:08, Peter Maydell wrote:
> On Mon, 16 Feb 2026 at 03:45, Richard Henderson
> <richard.henderson@linaro.org> wrote:
>>
>> RFC mostly because the kernel support is not yet upsteam.
>> This is based on
>>
>> https://lore.kernel.org/linux-arm-kernel/20251223-kvm-arm64-sme-v9-0-8be3867cb883@kernel.org/
>>
>> Properly testing this will take more time.  I'm not 100%
>> sure how to confirm that the SME registers have the correct
>> value across migration.
> 
> Am I right that patches 2-8 in here:
> 
>>    target/arm: Remove aarch64 test for kvm
>>    target/arm: Move kvm_arm_sve_get_vls within kvm.c
>>    target/arm: Init sve_vq in kvm_arm_set_cpu_features_from_host
>>    target/arm: Move kvm test out of cpu_arm_set_sve
>>    target/arm: Drop kvm_arm_sve_supported
>>    target/arm: Remove kvm test in arm_set_pmu
>>    target/arm: Drop kvm_arm_pmu_supported
> 
> are preparatory cleanups that don't depend on the new
> linux-headers changes?
> 
> (also maybe 10 and 11)

Yes, 2-8,10,11 could all go in now.

r~

On 2/25/26 15:24, Richard Henderson wrote:
> On 2/25/26 04:08, Peter Maydell wrote:
>> On Mon, 16 Feb 2026 at 03:45, Richard Henderson
>> <richard.henderson@linaro.org> wrote:
>>>
>>> RFC mostly because the kernel support is not yet upsteam.
>>> This is based on
>>>
>>> https://lore.kernel.org/linux-arm-kernel/20251223-kvm-arm64-sme- 
>>> v9-0-8be3867cb883@kernel.org/
>>>
>>> Properly testing this will take more time.  I'm not 100%
>>> sure how to confirm that the SME registers have the correct
>>> value across migration.
>>
>> Am I right that patches 2-8 in here:
>>
>>>    target/arm: Remove aarch64 test for kvm
>>>    target/arm: Move kvm_arm_sve_get_vls within kvm.c
>>>    target/arm: Init sve_vq in kvm_arm_set_cpu_features_from_host
>>>    target/arm: Move kvm test out of cpu_arm_set_sve
>>>    target/arm: Drop kvm_arm_sve_supported
>>>    target/arm: Remove kvm test in arm_set_pmu
>>>    target/arm: Drop kvm_arm_pmu_supported
>>
>> are preparatory cleanups that don't depend on the new
>> linux-headers changes?
>>
>> (also maybe 10 and 11)
> 
> Yes, 2-8,10,11 could all go in now.

Indeed, we may want all of those prior to

https://lore.kernel.org/qemu-devel/20260115-sme2-hvf-v2-2-2eca481bd7ee@linaro.org/

and the change therein to arm_cpu_sme_finalize.


r~

On Wed, 25 Feb 2026 at 04:28, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 2/25/26 15:24, Richard Henderson wrote:
> > On 2/25/26 04:08, Peter Maydell wrote:
> >> On Mon, 16 Feb 2026 at 03:45, Richard Henderson
> >> <richard.henderson@linaro.org> wrote:
> >>>
> >>> RFC mostly because the kernel support is not yet upsteam.
> >>> This is based on
> >>>
> >>> https://lore.kernel.org/linux-arm-kernel/20251223-kvm-arm64-sme-
> >>> v9-0-8be3867cb883@kernel.org/
> >>>
> >>> Properly testing this will take more time.  I'm not 100%
> >>> sure how to confirm that the SME registers have the correct
> >>> value across migration.
> >>
> >> Am I right that patches 2-8 in here:
> >>
> >>>    target/arm: Remove aarch64 test for kvm
> >>>    target/arm: Move kvm_arm_sve_get_vls within kvm.c
> >>>    target/arm: Init sve_vq in kvm_arm_set_cpu_features_from_host
> >>>    target/arm: Move kvm test out of cpu_arm_set_sve
> >>>    target/arm: Drop kvm_arm_sve_supported
> >>>    target/arm: Remove kvm test in arm_set_pmu
> >>>    target/arm: Drop kvm_arm_pmu_supported
> >>
> >> are preparatory cleanups that don't depend on the new
> >> linux-headers changes?
> >>
> >> (also maybe 10 and 11)
> >
> > Yes, 2-8,10,11 could all go in now.
>
> Indeed, we may want all of those prior to
>
> https://lore.kernel.org/qemu-devel/20260115-sme2-hvf-v2-2-2eca481bd7ee@linaro.org/
>
> and the change therein to arm_cpu_sme_finalize.

OK, I've applied 2-8 and 10-11 to target-arm.next.

thanks
-- PMM

On Mon, 16 Feb 2026 at 03:45, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> RFC mostly because the kernel support is not yet upsteam.
> This is based on
>
> https://lore.kernel.org/linux-arm-kernel/20251223-kvm-arm64-sme-v9-0-8be3867cb883@kernel.org/
>
> Properly testing this will take more time.  I'm not 100%
> sure how to confirm that the SME registers have the correct
> value across migration.
>
> I'm thinking of a test case in which the ZArray is loaded,
> the test program pauses, migration or vm save/load initiated,
> and the ZArray contents are verified after continuing.
> But anything that takes timing into account like that
> seems way sketchy, so I dunno.

You could avoid the timing dependency by having a test
harness that combined QMP and the gdbstub, so that your
test program does "set up registers; bkpt; ..." and then
you wait for the gdbstub to inform you that the VM has
stopped at the breakpoint, before doing a vmsave over QMP.
Having to manage two communications channels to the QEMU
process might be a bit tedious, though.

(We could avoid the two-channels thing by adding a
gdbstub QEMU-specific maintenance packet for "execute
this monitor command" but unless we think that would be
actively helpful for users it seems a bit hacky.)

-- PMM