Re: CVS commit: src/sys/arch/powerpc

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

On Sun, Nov 07, 2010 at 01:46:06PM +1100, Simon Burge wrote:
> "Masao Uebayashi" wrote:
> 
> > Module Name:        src
> > Committed By:       uebayasi
> > Date:               Sat Nov  6 16:36:27 UTC 2010
> > 
> > Modified Files:
> > 
> >     src/sys/arch/powerpc/ibm4xx: pmap.c
> >     src/sys/arch/powerpc/include/ibm4xx: vmparam.h
> > 
> > Log Message:
> > 
> > Merge from uebayasi-xip:
> > ----------------------------
> > revision 1.60.2.5
> > date: 2010/08/14 02:09:57;  author: uebayasi;  state: Exp;  lines: +2 -1
> > Teach TLB miss handler (pmap_tlbmiss()) to map "Expansion ROM" area as
> > PA == VA.  Now we don't need to reserve a TLB entry for it.
> > ----------------------------
> 
> At a quick glance, this seems to hard-wire in device addresses which may
> not be the same on every ibm4xx platform (the 0xef000000 address).
> 
> Also I'm not sure I like the idea of modifying a general pmap to have
> knowledge of device-specific "Expansion ROM" address ranges.  Are these
> _always_ guaranteed to live in the address range you've specified or
> is there a chance a ROM could be mapped at different addresses on some
> boards?  The change as is also limits expansion ROMs to a bit over
> 256MB which mightn't be a problem now but also indicates a problem with
> hardcoding specific values in a general pmap.
> 
> I'm not sure what the "correct" way of doing this is.  I think I'd
> prefer to see some sort of registration of expansion ROM space that you
> want to reserve, but would need to put some more thought in to it.

I'm sure what the correct way should be.

This is part of fault handler specific to CPU.  If we decide to
map part kernel VA to fixed addreess backed by fixed pages on this
CPU, we *resolve* it first.  Otherwise we'll try more general path.

So, we follow the strict definition that pmap(9) manages per-virtual
space (proc) address translation information, this pmap_tlbmiss()
breaks the rule.

> 
> If this change was to remain in its current form, the comment
> immediately above the change you made in the tlb miss handler is now
> incorrect and would need to be adjusted.
> 
> Cheers,
> Simon.