Amit Machhiwal <[email protected]> writes: > On 2026/06/16 05:38 PM, Ritesh Harjani wrote: >> Amit Machhiwal <[email protected]> writes: >> >> >> > diff --git a/arch/powerpc/include/asm/reg.h >> >> > b/arch/powerpc/include/asm/reg.h >> >> > index 3449dd2b577d..7472b9522f71 100644 >> >> > --- a/arch/powerpc/include/asm/reg.h >> >> > +++ b/arch/powerpc/include/asm/reg.h >> >> > @@ -1356,6 +1356,7 @@ >> >> > #define PVR_ARCH_300 0x0f000005 >> >> > #define PVR_ARCH_31 0x0f000006 >> >> > #define PVR_ARCH_31_P11 0x0f000007 >> >> > +#define PVR_ARCH_INVALID 0xffffffff >> >> >> >> Logical processor version is defined as part of the PAPR spec. We should >> >> ensure that this invalid PVR is also documented in the PAPR spec. >> >> >> >> If you have already taken care of that, then please confirm and feel free >> >> to add: >> > >> > Regarding the PAPR specification documentation: The PAPR spec documents >> > the valid Processor Version Register (PVR) values for each processor >> > generation (POWER8, POWER9, POWER10, POWER11, etc.). However, the >> > PVR_ARCH_INVALID value (0xffffffff) introduced in this patch series is a >> > KVM implementation detail used internally to mark invalid compatibility >> > mode requests - it's not an architectural value that would be defined in >> > PAPR itself. >> > >> > The validation logic and the use of PVR_ARCH_INVALID as a sentinel value >> > are documented in the kernel code and commit message. >> > >> >> But that still worries me on what if PAPR wants to re-use this value for >> some other purpose in future. > > This is a valid concern about potential future conflicts with PAPR. > However, I'd like to point out that PAPR explicitly specifies: > > "The first byte of the logical processor version value shall be 0x0F." > > Since PVR_ARCH_INVALID (0xffffffff) has a first byte of 0xFF, it's > explicitly outside the valid PAPR-defined range for logical PVR values. > This means there shouldn't be any risk of future conflict with PAPR > specifications. >
aah ok.. That make sense. Thanks for confirming that. Can we please update a small comment in the code and log this info, maybe something like: /* * PAPR specifies that the first byte of a valid logical PVR value is * 0x0f. 0xffffffff therefore lies permanently outside the PAPR-defined * range and is safe to repurpose as a kernel-internal sentinel. KVM * stores it in vc->arch_compat when userspace requests an unsupported * compatibility mode (e.g. Power11 on a Power10 compat host); * kvmppc_sanity_check() detects this and prevents the vCPU from running * until a valid arch_compat is set. */ #define PVR_ARCH_INVALID 0xffffffff -ritesh
