Re: [PATCH v5 07/10] KVM: arm64: Treat CTR_EL0 as a VM feature ID register

[Oliver Upton <oliver.upton@linux.dev>]

On Mon, Sep 09, 2024 at 05:16:55PM +0000, Shameerali Kolothum Thodi wrote:
> > > It should be safe, as a PIPT CMO always does at least the same as
> > > VIPT, and potentially more if there is aliasing.
> > 
> > +1, there was no particular reason why this wasn't handled before.
> > 
> > We should be careful to only allow userspace to select VIPT or PIPT (where
> > permissible), and not necessarily any value lower than what's reported by
> > hardware.
> 
> VIPT 0b10
> PIPT 0b11
> 
> Ok. Just to clarify that " not necessarily any value lower than what's reported by
> hardware" means userspace can set PIPT if hardware supports VIPT?

By that I meant we disallow userspace from selecting AIVIVT (0b01) and
VPIPT (0b00). The former is reserved in ARMv8, and I don't think anyone
has ever built the latter.

> Based on this,
> " If we have differing I-cache policies, report it as the weakest - VIPT." , I was thinking
> the other way around(see "safe to downgrade PIPT to VIPT"). But Marc also
> seems to suggest PIPT CMO ends up doing atleast same as VIPT and more, so it looks like
> the other way. If that's the case, what does that "report it as the weakest" means for host?

PIPT is the non-aliasing flavor of I$. Using a VIPT software model on
PIPT will lead to overinvalidating, but still correct. Cannot do it the
other way around.

-- 
Thanks,
Oliver