PAT & pmap(9) changes (was Re: CVS commit: src)

[David Young <dyoung%pobox.com@localhost>]

On Tue, Jul 06, 2010 at 08:50:36PM +0000, Christoph Egger wrote:
> Module Name:  src
> Committed By: cegger
> Date:         Tue Jul  6 20:50:36 UTC 2010
> 
> Modified Files:
>       src/share/man/man9: pmap.9
>       src/sys/arch/amd64/include: pte.h
>       src/sys/arch/hppa/include: pmap.h
>       src/sys/arch/i386/include: pte.h
>       src/sys/arch/mips/include: pmap.h
>       src/sys/arch/mips/mips: pmap.c
>       src/sys/arch/sgimips/sgimips: bus.c
>       src/sys/arch/x86/include: cpuvar.h pmap.h specialreg.h
>       src/sys/arch/x86/x86: bus_space.c cpu.c pmap.c
>       src/sys/arch/xen/x86: cpu.c
> Added Files:
>       src/sys/arch/x86/include: pte.h
> 
> Log Message:
> Turn PMAP_NOCACHE into MI flag.
> Add MI flags PMAP_WRITE_COMBINE, PMAP_WRITE_BACK, PMAP_NOCACHE_OVR.
> Update pmap(9) manpage.
> 
> hppa: Remove MD PMAP_NOCACHE flag as it exists as MI flag
> mips: Rename MD PMAP_NOCACHE to PGC_NOCACHE.
> 
> x86: Implement new MI flags using Page-Attribute Tables.
> x86: Implement BUS_SPACE_MAP_PREFETCHABLE.
> 
> Patch presented on tech-kern@:
> http://mail-index.netbsd.org/tech-kern/2010/06/30/msg008458.html
> 
> No comments on this last version.

Some of us scarcely have had time to reply to the second version. :-/

I don't think that a developer can predict from the manual page what
effect the memory-type flags will have.  Some combination of the doco,
API, and implementation needs improvement.

The x86 implementation gives the kernel more than one opportunity to
program conflicting memory types on the same physical page.  The first
opportunity to set conflicting types is an MI flag, PMAP_NOCACHE_OVR,
that caters to a quirk of x86 where the "uncacheable" page attribute
need not have "last say" on a page's memory type, but the MTRR can
override.  The second opportunity to set conflicting types is by
entering two mappings for the same page, VA1 -> PA and VA2 -> PA, VA1 !=
VA2.

Considering the potential conflicts, it seems that the memory-type flags
are all "hints."  In that case, they should be described as such in the
documentation, and there is no use for the hint PMAP_NOCACHE_OVR, which
is identical to the PMAP_NOCACHE hint.

If the memory-type flags are not intended to be hints, but the
implementation must obey the flags; or if sometimes the flags are hints,
and sometimes they are mandatory; then either the implementation or the
implementation and the API need improvement.  The implementation needs
to check for conflicts.  The API may need to accept both mandatory
memory types and hints.  In this way, the behavior is predictable.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933