On Mon, 18 Mar 2024 16:14:22 +0000,
David Woodhouse <[email protected]> wrote:
>
> The PSCI v1.3 spec (https://developer.arm.com/documentation/den0022,
> currently in Alpha state, hence 'RFC') adds support for a SYSTEM_OFF2
> function enabling a HIBERNATE_OFF state which is analogous to ACPI S4.
> This will allow hosting environments to determine that a guest is
> hibernated rather than just powered off, and ensure that they preserve
> the virtual environment appropriately to allow the guest to resume
> safely (or bump the hardware_signature in the FACS to trigger a clean
> reboot instead).
>
> This adds support for it to KVM, exactly the same way as the existing
> support for SYSTEM_RESET2 as added in commits d43583b890e7 ("KVM: arm64:
> Expose PSCI SYSTEM_RESET2 call to the guest") and 34739fd95fab ("KVM:
> arm64: Indicate SYSTEM_RESET2 in kvm_run::system_event flags field").
>
> Back then, KVM was unconditionally bumped to expose PSCI v1.1. This
> means that a kernel upgrade causes guest visible behaviour changes
> without any explicit opt-in from the VMM, which is... unconventional. In
> some cases, a PSCI update isn't just about new optional calls; PSCI v1.2
> for example adds a new permitted error return from the existing CPU_ON
> function.
>
> There *is* a way for a VMM to opt *out* of newer PSCI versions... by
> setting a per-vCPU "special" register that actually ends up setting the
> PSCI version KVM-wide. Quite why this isn't just a simple KVM_CAP, I
> have no idea.
Because the expectations are that the VMM can blindly save/restore the
guest's state, including the PSCI version, and restore that blindly.
KVM CAPs are just a really bad design pattern for this sort of things.
M.
--
Without deviation from the norm, progress is not possible.
On Mon, 2024-03-18 at 16:57 +0000, Marc Zyngier wrote:
>
> >
> > There *is* a way for a VMM to opt *out* of newer PSCI versions... by
> > setting a per-vCPU "special" register that actually ends up setting the
> > PSCI version KVM-wide. Quite why this isn't just a simple KVM_CAP, I
> > have no idea.
>
> Because the expectations are that the VMM can blindly save/restore the
> guest's state, including the PSCI version, and restore that blindly.
> KVM CAPs are just a really bad design pattern for this sort of things.
Hm, am I missing something here? Does the *guest* get to set the PSCI
version somehow, and opt into the latest version that it understands
regardless of what the firmware/host can support?
Because if not, surely it's just part of the basic shape of the
machine, like "how many vCPUs does it have". You don't need to be able
to query it back again.
I don't think we ever aspired to be able to hand an arbitrary KVM fd to
a userspace VMM and have the VMM be able to drive that VM without
having any a priori context, did we?