Subject: Re: port-mips/31915: provide centralized wired_map logic
To: Izumi Tsutsui <>
From: Garrett D'Amore <>
List: port-mips
Date: 10/27/2005 12:34:21
Izumi Tsutsui wrote:

>[well, please don't quote whole messages. all messages are filed in gnats]
>In artcile <>
> 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