On 2026/06/16 06:39 PM, Ritesh Harjani wrote: > 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:
Sure, Ritesh. I can certainly do that in the next version. Thanks, Amit. > > /* > * 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 >
