Re: re: PAT support

["Christoph Egger" <Christoph_Egger%gmx.de@localhost>]

> 
> 
> 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