dmcq (dmcq.delete@this.fano.co.uk) on September 14, 2021 9:34 am wrote:
> anon (anon.delete@this.ymous.org) on September 14, 2021 3:17 am wrote:
> > Hugo Décharnes (hdecharn.delete@this.outlook.fr) on September 10, 2021 6:59 am wrote:
> > > No need to invalidate at context switch. Only when ASID or VMID is reclaimed. That is identified by
> > > a TLBI. And the line do not have to be written-back, just marked non-hitable but still snoopable.
> >
> > Yes I think I got a bit carried away here and forgot to think. Thank you for the clarification.
> >
> > I have one question regarding not doing a TLB check on each load though. What is the safety net when
> > you have an inflight store to VA A and an inflight load from VA B and A and B are aliased ?
> >
> > Let's assume you enforce only one alias in the L1D. If currently the resident alias is A, the load
> > will return L1D data and miss the dependency with the store (since A != B, and so far we are not
> > getting a translation for the load because it hit in L1D). If currently the resident alias is B,
> > then the load will miss and go get a translation, to realize that there is aliasing going on, and
> > then it is not obvious that it would not still get the L1D data rather than the store data.
> >
> > So, basically, how do you do memory disambiguation without having each load
> > get a translation just so it can compare to stores in the PA space ? I suppose
> > you could do a pessimistic check with just the set and offset bits ?
>
> For a VIPT L1 cache you need to get the address translated anyhow before using the data
> so the permissions can be got from the TLB. (or you can use it and check afterwards but
> that leads to sideband hacks!) VIVT can avoid the TLB dependency but then the cache needs
> to store the permisions for a particular process or the system with each cache line.

I suspect it's simpler: the cache coherency protocol will require that at most a single copy is in writable state. I.e., VIVT is layered on top of the existing VIPT mechanism.