85bd0ba1ff
Although we've implemented PSCI 0.1, 0.2 and 1.0, we expose either 0.1 or 1.0 to a guest, defaulting to the latest version of the PSCI implementation that is compatible with the requested version. This is no different from doing a firmware upgrade on KVM. But in order to give a chance to hypothetical badly implemented guests that would have a fit by discovering something other than PSCI 0.2, let's provide a new API that allows userspace to pick one particular version of the API. This is implemented as a new class of "firmware" registers, where we expose the PSCI version. This allows the PSCI version to be save/restored as part of a guest migration, and also set to any supported version if the guest requires it. Cc: stable@vger.kernel.org #4.16 Reviewed-by: Christoffer Dall <cdall@kernel.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> |
||
---|---|---|
.. | ||
arm | ||
devices | ||
00-INDEX | ||
amd-memory-encryption.rst | ||
api.txt | ||
cpuid.txt | ||
halt-polling.txt | ||
hypercalls.txt | ||
locking.txt | ||
mmu.txt | ||
msr.txt | ||
nested-vmx.txt | ||
ppc-pv.txt | ||
review-checklist.txt | ||
s390-diag.txt | ||
timekeeping.txt | ||
vcpu-requests.rst |