Re: PAT support

[Terence Ripperda <tripperda@nvidia.com>]

On Tue, Apr 13, 2004 at 01:36:13AM -0700, apw@shadowen.org wrote:
> But I did notice there appear to be no notes or
> warnings on the issues of using PAT based mappings.  Cirtainly there are
> some _very_ onerus restrictions which I have personally tested and found to
> be true :(.  Perhaps we could get some big fat warning style comments.

where would you like to see such warnings? arguably, all of the dangerous conditions should be handled by this core code to avoid problems (such as only using the first 4 pat entries, flushing the correct caches when updating the pat entries or pte bits). these problems really aren't all that different than any other cache aliasing/pte flushing issues that always exist, right?

> + * According to the INTEL documentation it is the systems responsibility
> + * to ensure that the PAT registers are kept in agreement on all processors
> + * in a system.  Changing these registers must occu in a manner which
> + * maintains the consistency of the processor caches and translation
> + * lookaside buggers (TLB). 

absolutely. I tried to handle this by initializing the pat entries as each cpu comes online at boot time, with cache flushes. I think Andi mentioned flushing the TLBs as well, I'll check up on that to make sure I'm doing that as well.
 
> Also, I have confirmed that if you have any Intel processors which do not
> have the SS (Self Snoop) capability, you cannot have two independent
> mappings to a page with different cache attributes.  I have been hit by
> this and you get stale data returned from the cache.

certainly, that is more or less what this mechanism is intended to prevent. cmap_compare_cachings is an arch-dependent function, which allows architectures to allow/disallow different cache attributes. I certainly consider the current implementation to be a sample that needs some tweaking. for example, I forgot that I had allowed CACHED/NOCACHED overlaps, due to MTRRs that legally overlap like this. but that's probably not a situation we want for any other case, so I need to fix that.

Thanks,
Terence