On Wed, 11 Feb 2026 at 16:04, Sebastian Ott <[email protected]> wrote: > > 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));
I guess we need to define what we want. Things we need: - user/QMP/etc setting a value and reading it back should get back what they set - QEMU needs to keep working on a new kernel that defines a new PSCI version in the future - user reading the default value and then writing it back should succeed Things we might like: - ideally the setter would fail if the user picks a version KVM can't support, but I don't think we can conveniently determine this, so "fail vcpu init" may be as good as we can get without unnecessarily large amounts of effort I think this probably adds up to: - setter should accept any a.b value (for a,b fitting in [0,65535]) - getter can handle any value and turn it into a.b - make sure that setting it to an invalid value gives a helpful error on vcpu start Doing it this way, do we need a separate cpu->kvm_prop_psci_version, or could we directly read and write cpu_>psci_version ? thanks -- PMM
