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
