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.
BTW, thinking more about it, if we purely want this to be in kernel only,
can we instead add, something like:
bool kpvr_compat; /* Does kernel supports this PVR */
rather than re-using & overloading arch_compat which has values that
comes from PAPR spec?
Thoughts?
-ritesh
