On Mon, 16 Feb 2026, Peter Maydell wrote:
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:
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 for your suggestions! I've implemented them all and sent out a V6.
Sebastian
