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