> > > what's PAT? Sorry for my cryptic mail. It was 1:30am. I just wanted to send out the patch and go to bed.
PAT stands for Page-Attribute Table that extends the page-table entry format to provide memory caching capabilities on memory page-level. There is one PAT MSR which contains eight attribute fields numbered from PA0 to PA7. The PA fields hold the encoding of a memory type. The memory type of each PA field can be configured by writing them to the PAT MSR. The eight PA fields are selected using three bits from the page-table entries on x86: PAT, PCD (cache disable) and PWT (write through) The following memory types exist: - Uncacheable - Write-Combining - Write-Protect - Write-Through - Writeback - Uncacheable Minus Uncacheable: Reads and writes are uncached. Reads can't be speculative. This memory type is useful for memory-mapped IO devices where strict ordering of reads and writes is important. Write-Combining: Same as Uncacheable regarding to reads. Writes to this memory type can be combined internally by the processor and written to memory as a single write operation. For example, four word writes to consecutive addresses can be combined by the processor into a single quadword write, resulting in one memory access instead of four This memory type is useful for graphics-display memory buffers where the order of writes is not important. Write-Protect: Reads from memory of this type are cacheable and allocate cache lines on a read miss. Reads can be speculative. Write to memory of this type that hit the cache do not update the cache. Instead, all writes update main memory. This memory type is useful for shadowed-ROM memory where updates must be immediately visible to all devices that read the shadow locations. Write-Through: Reads from memory of this type are cacheable and allocaet cache lines on a read miss. Reads can be speculative. All writes update main memory, writes that hit in the cache update the cache line. Writes that miss the cache do not allocate a cache line. Writeback: Reads from memory of this type are cacheable and allocate cache lines on read miss. Reads can be speculative. All writes that hit in the cache update the cache line. Writes that miss the cache allocate a new cache line. This memory type provides the highest-possible performance and is the default memory type. Uncacheable Minus: Same as Uncacheable but can be override by MTRRs. Martin asked in a later mail if we can move the discussion to x86-only mailing lists. Well, not quite since I add MI PMAP flags to uvm/uvm_pmap.h: +/* + * Cache Type Encodings + */ +#define PMAP_CACHE_MASK 0x00000f00 + +/* All accesses are uncacheable. No speculative accesses. */ +#define PMAP_NOCACHE 0x00000100 /* [BOTH] */ + +/* All accesses are uncacheable. No speculative accesses. + * Writes are combined. */ +#define PMAP_WRITE_COMBINE 0x00000200 /* [BOTH] */ + +/* On reads, cachelines become shared or exclusive if allocated on cache miss. + * On writes, cachelines become modified on a cache miss. */ +#define PMAP_WRITE_BACK 0x00000300 /* [BOTH] */ + +/* = PMAP_NOCACHE but overrideable (e.g. on x86 by MTRRs) */ +#define PMAP_NOCACHE_OVR 0x00000400 /* [BOTH] */ + PMAP_NOCACHE corresponds to the memory type 'Uncacheable' PMAP_WRITE_COMBINE corresponds to the memory type 'Write-Combined' PMAP_WRITE_BACK corresponds to the memory type 'Writeback' PMA_NOCACHE_OVR corresponds to the memory type 'Uncacheable Minus' The other types make no sense to me to make them MI as I don't see where MI code handles access to shadow-ROMs, for example. If you agree on that decision or not is one point we need to discuss. Another point to discuss is whether the new MI pmap flags make sense to have on non-x86 ports. The patch implements above MI pmap flags for x86 using the x86 PAT feature. The patch also implements BUS_SPACE_MAP_PREFETCHABLE using the x86 PAT feature. The ports hp700 and sgimips implement PMAP_NOCACHE and call it PMAP_NOCACHE so the compiler says 'PMAP_NOCACHE redefined'. That is why I said in my first mail those ports need an update. > could you add a comment to pat.c, explaining > what this code is for? > > please make sure that pat_init() definition is in column 1 (aka KNF). > > (not sure the point of pat.h, i'd just merge it it into cpu.h or > similar.) Thanks for the hints. Will do so. Christoph