Re: [PATCH v3] KVM: PPC: Book3S HV: Validate arch_compat against host compatibility mode

[Ritesh Harjani (IBM) <ritesh.list@gmail.com>]

Amit Machhiwal <amachhiw@linux.ibm.com> writes:

> On 2026/06/16 05:38 PM, Ritesh Harjani wrote:
>> Amit Machhiwal <amachhiw@linux.ibm.com> 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