summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorAmit Machhiwal <amachhiw@linux.ibm.com>2026-07-14 23:24:32 +0530
committerMadhavan Srinivasan <maddy@linux.ibm.com>2026-08-03 14:00:51 +0530
commit884ea0283f4effac97ee8f451464a7d1be480d7c (patch)
treeab72b2771f240f8af1690c3b31c99f16a28d39f1 /tools/perf/scripts/python
parent5aabc192702defb8950e7c81b05c3f4ca8ee43ec (diff)
KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode
On IBM POWER systems, newer processor generations can operate in compatibility modes corresponding to earlier generations. This becomes relevant for nested virtualization, where nested KVM guests may need to run with a specific processor compatibility level. Currently, when running a nested KVM guest (L2) inside a Power11 pSeries logical partition (L1) booted in Power10 compatibility mode, the guest fails to boot while setting 'arch_compat'. This happens because the CPU class is derived from the hardware PVR (via mfspr()), which reflects the physical processor generation (Power11), rather than the effective compatibility mode (Power10). As a result, userspace may request a Power11 arch_compat for the L2 guest. However, the L1 partition, running in Power10 compatibility, has only negotiated support up to Power10 with the Power Hypervisor (L0). When H_GUEST_SET_STATE is invoked with a Power11 Logical PVR, the hypervisor rejects the request, leading to a late guest boot failure: KVM-NESTEDv2: couldn't set guest wide elements [..KVM reg dump..] This situation should be detected earlier and rejected by KVM. Without proper validation, if userspace ignores the error, the guest may continue to boot in Power11 raw mode on a Power10 compatibility host, which should not be allowed. Introduce a validation mechanism that detects unsupported arch_compat values early in the guest initialization path. When an unsupported arch_compat is requested (e.g., Power11 on a Power10 compatibility mode host), kvmppc_set_arch_compat() uses cpu_has_feature(CPU_FTR_P11_PVR) to detect the mismatch and sets arch_compat to PVR_ARCH_INVALID (0xffffffff). This sentinel value is architecturally safe: PAPR specifies that valid logical PVR values must have 0x0f as the first byte, ensuring 0xffffffff lies permanently outside the specification-defined range. Setting this value triggers kvmppc_sanity_check() to mark the vCPU as invalid by setting vcpu->arch.sane to false. On the next vCPU run, kvmppc_vcpu_run_hv() checks this flag and returns -EINVAL, preventing the guest from running with an invalid processor compatibility configuration. With this, when a Power11 arch_compat is requested on a Power10 compatibility mode host, the guest fails early during boot with: error: kvm run failed Invalid argument This provides a much clearer failure mode compared to the previous behavior where the guest could boot in Power11 raw mode (if userspace ignored the error) or fail late during H_GUEST_SET_STATE. Suggested-by: Vaibhav Jain <vaibhav@linux.ibm.com> Reviewed-by: Vaibhav Jain <vaibhav@linux.ibm.com> Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com> Acked-by: Gautam Menghani <gautam@linux.ibm.com> Cc: stable@vger.kernel.org # v6.13+ Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Reviewed-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com> Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260714175432.86388-1-amachhiw@linux.ibm.com
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions