On Thu, 11 Sep 2025, Peter Maydell wrote:
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...
Yes we already are ;-) See this series from Cornelia:
https://lore.kernel.org/qemu-devel/20250414163849.321857-1-cohuck@xxxxxxxxxx/
And this from Eric:
https://lore.kernel.org/qemu-devel/20250911134324.3702720-1-eric.auger@xxxxxxxxxx/
Both will help mitigate register differences for a backwards/downgrade
migration.
Sebastian
