> -----Original Message----- > From: Oliver Upton <oliver.upton@xxxxxxxxx> > Sent: Monday, September 9, 2024 6:51 PM > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@xxxxxxxxxx> > Cc: Marc Zyngier <maz@xxxxxxxxxx>; kvmarm@xxxxxxxxxxxxxxx; Sebastian Ott > <sebott@xxxxxxxxxx>; James Morse <james.morse@xxxxxxx>; Suzuki K > Poulose <suzuki.poulose@xxxxxxx>; yuzenghui <yuzenghui@xxxxxxxxxx>; > kvm@xxxxxxxxxxxxxxx; Shaoqin Huang <shahuang@xxxxxxxxxx>; Eric Auger > <eric.auger@xxxxxxxxxx>; Wangzhou (B) <wangzhou1@xxxxxxxxxxxxx> > Subject: Re: [PATCH v5 07/10] KVM: arm64: Treat CTR_EL0 as a VM feature ID > register > > 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. Ok. Thanks both. I will send out a patch soon. And now to the elephant in the room, handling MIDR differences and associated errata management 😊 Marc, you mentioned about a prototype solution you have a while back[0], has that been shared public? Also not sure ARM has any plans to make this a specification soon. I was thinking of handling this in userspace for now by ignoring the MIDR write error on Migration and keeping the host MIDR value for destination VM. This is for use cases where we know that the hosts doesn't have any MIDR based errata or errata difference doesn't matter and assuming the user knows what they are doing. Please let me know, if there are any other suggestions or work in progress on this one. Thanks, Shameer [0] https://lore.kernel.org/linux-arm-kernel/867ct8mnel.wl-maz@xxxxxxxxxx/
