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.