On Tue, 2024-03-12 at 15:24 +0000, Marc Zyngier wrote: > > > Strictly, we should perhaps also allow the guest to detect PSCI v1.3, > > but when v1.1 was added in commit 512865d83fd9 it was done > > unconditionally, which seems wrong. Shouldn't we have a way for > > userspace to control what gets exposed, rather than silently changing > > the guest behaviour with newer host kernels? Should I add a > > KVM_CAP_ARM_PSCI_VERSION? > > Do you mean something like 85bd0ba1ff98? Ew :) That isn't quite what I was thinking, no. I wasn't thinking of something that would default to the latest, and would have a per-vCPU way of setting what's essentially a KVM-wide configuration. So if current userspace doesn't want the environment it exposes to guests to be randomly changed by a kernel upgrade in the future, it needs to explicitly use KVM_ARM_SET_REG on any one of the vCPUs, to set KVM_REG_ARM_PSCI_VERSION to KVM_ARM_PSCI_1_1? It isn't just new optional features; PSCI v1.2 added new error returns from CPU_ON for example. Should guests start to see those, just because the host kernel got upgraded? Now I see it, I suppose we can extend it to v1.2 (and v1.3 when that's eventually published for real). Should we really continue to increment the *default* though?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
