On Wed, 11 Feb 2026, Peter Maydell wrote:
On Wed, 11 Feb 2026 at 15:37, Sebastian Ott <[email protected]> wrote:
Hi Peter,
On Fri, 6 Feb 2026, Peter Maydell wrote:
On Tue, 2 Dec 2025 at 16:09, Sebastian Ott <[email protected]> wrote:
+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?
Oh, I see -- we're reporting back cpu->psci_version here, which
indeed could be the value set by KVM. I misread and assumed
this was just reading back the field that the setter sets,
which is kvm_prop_psci_version (and which I think will only
be set via the setter and so isn't ever a value the setter
doesn't know about).
That does flag up a bug in this patch, though: if I set
a QOM property via the setter function and then read its
value via the getter function I ought to get back what
I just wrote.
Meaning this should be something like below?
static char *kvm_get_psci_version(Object *obj, Error **errp)
{
ARMCPU *cpu = ARM_CPU(obj);
return g_strdup_printf("%d.%d",
(int) PSCI_VERSION_MAJOR(cpu->kvm_prop_psci_version),
(int) PSCI_VERSION_MINOR(cpu->kvm_prop_psci_version));
}
