Re: [PATCH v4 2/2] target/arm/kvm: add kvm-psci-version vcpu property

[Sebastian Ott <sebott@redhat.com>]

Hi Peter,

On Fri, 6 Feb 2026, Peter Maydell wrote:
> On Tue, 2 Dec 2025 at 16:09, Sebastian Ott <sebott@redhat.com> wrote:
>>
>> Provide a kvm specific vcpu property to override the default
>> (as of kernel v6.13 that would be PSCI v1.3) PSCI version emulated
>> by kvm. Current valid values are: 0.1, 0.2, 1.0, 1.1, 1.2, and 1.3
>>
>> Note: in order to support PSCI v0.1 we need to drop vcpu
>> initialization with KVM_CAP_ARM_PSCI_0_2 in that case.
>>
>> Signed-off-by: Sebastian Ott <sebott@redhat.com>
>> Reviewed-by: Eric Auger <eric.auger@redhat.com>
>> ---
>>  docs/system/arm/cpu-features.rst |  5 +++
>>  target/arm/cpu.h                 |  6 +++
>>  target/arm/kvm.c                 | 64 +++++++++++++++++++++++++++++++-
>>  3 files changed, 74 insertions(+), 1 deletion(-)
>
> Hi; this patch seems generally reasonable to me as a way to handle
> this kind of "control" register; for more discussion I wrote a
> longer email in reply to Eric's series handling other kinds of
> migration failure:
> https://lore.kernel.org/qemu-devel/CAFEAcA-gi42JObOjLuPudABX8WRdWf5SzSbkzU-bd06ecF1Vog@mail.gmail.com/T/#me03ebff8dbd8f58189cd98c3a21812781693277e
>
> Unless discussion in that thread reveals that we have so many of
> this kind of "control" knob that we would prefer a generic
> solution rather than per-knob user-friendly names and values,
> I'm OK with taking this patch without completely resolving the
> design discussion on that other series first.
>
> My review comments below are fairly minor, and patch 1 of
> this series has already been applied upstream now.

Thanks for your comments! I've addressed them all and sent out V5.


>> +static char *kvm_get_psci_version(Object *obj, Error **errp)
>> +{
>> +    ARMCPU *cpu = ARM_CPU(obj);
>> +    const struct psci_version *ver;
>> +
>> +    for (ver = psci_versions; ver->number != -1; ver++) {
[...]
>> +        if (ver->number == cpu->psci_version)
>> +            return g_strdup(ver->str);
>> +    }
>> +
>> +    return g_strdup_printf("Unknown PSCI-version: %x", cpu->psci_version);
>
> Is this ever possible?

Hm, not sure actually - what if there's a new kernel/qemu implementing
psci version 1.4 and then you migrate to a qemu that doesn't know about
1.4?

Thanks,
Sebastian