On Thu, 11 Sept 2025 at 17:29, Sebastian Ott <sebott@xxxxxxxxxx> wrote: > > On Thu, 11 Sep 2025, Peter Maydell wrote: > > On Thu, 11 Sept 2025 at 16:59, Sebastian Ott <sebott@xxxxxxxxxx> wrote: > >> > >> On Thu, 11 Sep 2025, Peter Maydell wrote: > >>> On Thu, 11 Sept 2025 at 15:49, Sebastian Ott <sebott@xxxxxxxxxx> wrote: > >>>> > >>>> This series adds a vcpu knob to request a specific PSCI version > >>>> from KVM via the KVM_REG_ARM_PSCI_VERSION FW register. > >>>> > >>>> Note: in order to support PSCI v0.1 we need to drop vcpu > >>>> initialization with KVM_CAP_ARM_PSCI_0_2 in that case. > >>>> Alternatively we could limit support to versions >=0.2 . > >>>> > >>>> Sebastian Ott (2): > >>>> target/arm/kvm: add constants for new PSCI versions > >>>> target/arm/kvm: add kvm-psci-version vcpu property > >>> > >>> Could we have some rationale, please? What's the use case > >>> where you might need to specify a particular PSCI version? > >> > >> The use case is migrating between different host kernel versions. > >> Per default the kernel reports the latest PSCI version in the > >> KVM_REG_ARM_PSCI_VERSION register (for KVM_CAP_ARM_PSCI_0_2) - > >> when that differs between source and target a migration will fail. > >> > >> This property allows to request a PSCI version that is supported by > >> both sides. Specifically I want to support migration between host > >> kernels with and without the following Linux commit: > >> 8be82d536a9f KVM: arm64: Add support for PSCI v1.2 and v1.3 > > > > So if the destination kernel is post that commit and the > > source kernel pre-dates it, do we fail migration? > > This case works with current qemu without any changes, since on > target qemu would write the register value it has stored from > the source side (QEMU_PSCI_VERSION_1_1) and thus requests kvm > on target to emulate that version. > > > Or is > > this only a migration failure when the destination doesn't > > support the PSCI version we defaulted to at the source end? > > Yes, this doesn't work with current qemu. On target qemu would > write QEMU_PSCI_VERSION_1_3 to the KVM_REG_ARM_PSCI_VERSION > register but that kernel doesn't know this version and the > migration will fail. I was under the impression that trying to migrate backwards from a newer kernel to an older one was likely to fail for various reasons (notably "new kernel reports a new system register the old one doesn't") ? Perhaps we should think about the problem in a wider scope than just the PSCI version... thanks -- PMM
