Documentation/virt/kvm/arm/psci.rst

   1 .. SPDX-License-Identifier: GPL-2.0
   2
   3 =========================================
   4 Power State Coordination Interface (PSCI)
   5 =========================================
   6
   7 KVM implements the PSCI (Power State Coordination Interface)
   8 specification in order to provide services such as CPU on/off, reset
   9 and power-off to the guest.
  10
  11 The PSCI specification is regularly updated to provide new features,
  12 and KVM implements these updates if they make sense from a virtualization
  13 point of view.
  14
  15 This means that a guest booted on two different versions of KVM can
  16 observe two different "firmware" revisions. This could cause issues if
  17 a given guest is tied to a particular PSCI revision (unlikely), or if
  18 a migration causes a different PSCI version to be exposed out of the
  19 blue to an unsuspecting guest.
  20
  21 In order to remedy this situation, KVM exposes a set of "firmware
  22 pseudo-registers" that can be manipulated using the GET/SET_ONE_REG
  23 interface. These registers can be saved/restored by userspace, and set
  24 to a convenient value if required.
  25
  26 The following register is defined:
  27
  28 * KVM_REG_ARM_PSCI_VERSION:
  29
  30   - Only valid if the vcpu has the KVM_ARM_VCPU_PSCI_0_2 feature set
  31     (and thus has already been initialized)
  32   - Returns the current PSCI version on GET_ONE_REG (defaulting to the
  33     highest PSCI version implemented by KVM and compatible with v0.2)
  34   - Allows any PSCI version implemented by KVM and compatible with
  35     v0.2 to be set with SET_ONE_REG
  36   - Affects the whole VM (even if the register view is per-vcpu)
  37
  38 * KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
  39     Holds the state of the firmware support to mitigate CVE-2017-5715, as
  40     offered by KVM to the guest via a HVC call. The workaround is described
  41     under SMCCC_ARCH_WORKAROUND_1 in [1].
  42
  43   Accepted values are:
  44
  45     KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL:
  46       KVM does not offer
  47       firmware support for the workaround. The mitigation status for the
  48       guest is unknown.
  49     KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL:
  50       The workaround HVC call is
  51       available to the guest and required for the mitigation.
  52     KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED:
  53       The workaround HVC call
  54       is available to the guest, but it is not needed on this VCPU.
  55
  56 * KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
  57     Holds the state of the firmware support to mitigate CVE-2018-3639, as
  58     offered by KVM to the guest via a HVC call. The workaround is described
  59     under SMCCC_ARCH_WORKAROUND_2 in [1]_.
  60
  61   Accepted values are:
  62
  63     KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
  64       A workaround is not
  65       available. KVM does not offer firmware support for the workaround.
  66     KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
  67       The workaround state is
  68       unknown. KVM does not offer firmware support for the workaround.
  69     KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
  70       The workaround is available,
  71       and can be disabled by a vCPU. If
  72       KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED is set, it is active for
  73       this vCPU.
  74     KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
  75       The workaround is always active on this vCPU or it is not needed.
  76
  77 .. [1] https://developer.arm.com/-/media/developer/pdf/ARM_DEN_0070A_Firmware_interfaces_for_mitigating_CVE-2017-5715.pdf