The following reply was made to PR port-mips/31915; it has been noted by GNATS.

From: "Garrett D'Amore" <garrett_damore@tadpole.com>
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Cc: gnats-bugs@NetBSD.org, port-mips@NetBSD.org
Subject: Re: port-mips/31915: provide centralized wired_map logic
Date: Thu, 27 Oct 2005 12:34:21 -0700

 Izumi Tsutsui wrote:
 
 >[well, please don't quote whole messages. all messages are filed in gnats]
 >
 >In artcile <43611BFA.3030306@tadpole.com>
 >garrett_damore@tadpole.com wrote:
 >
 >  
 >
 >>I've thought some more about this.  I really think, pretty strongly, 
 >>that it is wrong for the wired_map logic to manage its own extents.
 >>    
 >>
 >
 >Well, we don't have to map device space always by wired map functions.
 >The lower wired map layer could have its own extent, and the upper
 >bus_space(9) layers could also manage their regions by own extents.
 >  
 >
 I think this creates a bit of additional complexity.  Because the upper 
 layer only knows about the VA space assigned by the lower layer, it has 
 to allocate the extent on demand, and subdivide it.  And if you want to 
 map a larger chunk of data than fits in the remaining (upper) extent, 
 then the upper layer winds up having to allocate another extent based on 
 some new VA that the lower gives it.  (I guess it could do this by 
 creating a large extent over all space, allocating the whole then, then 
 selectively freeing space as the lower wired layer gives it mappings.)
 
 >If required physical address is already mapped to VA by the other
 >request, upper layer can choose the VA range already allocated
 >rather than create another wired map.
 >In sys/arch/arc/arc/bus_space_{sparse,large}.c, wired_map function is
 >called only if the requested PA range is too large for KSEG2
 >mappings and it has not been mapped by another wired_map.
 >Isn't it okay? (maybe I overlook something though...)
 >  
 >
 I think that the problem is that ultimately you wind up with VA space 
 being carved up in some inconvienent ways.
 
 The PCI configuration code, for example, is going to allocate PCI 
 address space without regard to "gaps" in the address space that may be 
 created in matching VA space.  (These gaps get created because of needs 
 to map to other, non-contiguous, physical spaces.)
 
 So, in order to find a contiguous VA range, you may not be able to use 
 an existing TLB entry, where you otherwise could if the VA space was not 
 split at arbitrary points.
 
 Ultimately, my take on this is that having the upper layer manage the VA 
 extent is simpler.  Only one place to manage the address space, and it 
 provides the most flexibility for whatever the individual needs of the 
 specific port are, without imposing extra complication on ports that 
 have simpler needs.
 
 Btw, it would be pretty easy to take my work (with the latest split 
 EntryLo0 and EntryLo1 support), and call those functions from a more 
 "fully featured" wired map logic that did manage the VA address space on 
 its own.   I leave that as an exercise for the reader.  (A logical place 
 to do this, I think, would be in the ARC wired_map.c code.)
 
 You will note that I did not call my .c file wired_map.c, but rather 
 mips3_wired_map.c, in order to allow for the ARC specific wired_map 
 routines to coexist.
 
     -- Garrett
 
 >---
 >Izumi Tsutsui
 >  
 >