Re: re: PAT support

2010-05-19 Thread Christoph Egger

 
 
 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_MASK0x0f00
+
+/* All accesses are uncacheable. No speculative accesses. */
+#define PMAP_NOCACHE   0x0100  /* [BOTH] */
+
+/* All accesses are uncacheable. No speculative accesses.
+ * Writes are combined. */
+#define PMAP_WRITE_COMBINE 0x0200  /* [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_BACK0x0300  /* [BOTH] */
+
+/* = PMAP_NOCACHE but overrideable (e.g. on x86 by MTRRs) */
+#define PMAP_NOCACHE_OVR   0x0400  /* [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


xxxVERBOSE module?

2010-05-19 Thread Paul Goyette
From the comments in the GENERIC config files, the primary reason for 
omitting the various xxxVERBOSE options is to avoid including large text 
tables in the resulting kernel.  And I vaguely recall some spirited 
discussion back when the change was made to exclude these options by 
default.


Now that we have MODULAR kernels (at least on some architectures), I've 
been wondering if it might make sense to create a mod_verbose that could 
be loaded during start-up time and then unloaded after the machine is up 
and running.  (For plug-and-play situations, such as USB, the module 
could be reloaded and unloaded whenever a new device is added.)


Is this something that would be useful?


-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:   |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |  | pgoyette at netbsd.org  |
-


Re: PAT support

2010-05-19 Thread Christoph Egger
On 20.05.10 01:15, David Young wrote:
 On Wed, May 19, 2010 at 11:43:00AM +0200, Christoph Egger wrote:
 The following memory types exist:

- Uncacheable (UC)
- Write-Combining (WC)
- Write-Protect (WP)
- Write-Through (WT)
- Writeback (WB)
- Uncacheable Minus (UC-)
 
 IIUC, the memory type set by PAT applies at VA - PA mapping.

Yes, because it works on page-level.

 Can't one physical page be mapped at two VAs with conflicting memory types?
 
 On one physical range, can PAT and MTRR simultaneously set conflicting
 memory types?  Can we detect/avoid the conflict?

The memory types established by the PAT mechanism can be combined with
MTRR-established memory types to form an effective memory-type.

Reserved and undefined combinations of MTRR and PAT memory types result
in undefined behavior. If the MTRRs are disabled in implementations
that support the MTRR mechanism, the default memory type is set to
Uncacheable.

The combined effect of MTRR and PAT memory types:

PAT memory type  MTRR memory typeeffective memory type
UC   UC, WC, WP, WT, WB  UC
UC-  UC  UC
UC-  WC  WC
UC-  WP, WT, WB  UC
WC   —   WC
WP   UC  UC
WP   WC  UC
WP   WP  WP
WP   WT  UC
WP   WB  WP
WT   UC  UC
WT   WC, WP  UC
WT   WT, WB  WT
WB   UC  UC
WB   WC  WC
WB   WP  WP
WB   WT  WT
WB   WB  WB


 Are some memory types more suitable for a DMA buffer than others?

For MMIO you can use either Uncachable, Uncacheable Minus or Write-Combine.

 Where PAT is not available, can't we fall back to using a facility such
 as MTRR to set memory types?

Sure we can.

 
 Dave