Re: pmap_mmap

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

On Wed, Nov 17, 2010 at 04:07:04PM +0000, Eduardo Horvath wrote:
> On Thu, 18 Nov 2010, Masao Uebayashi wrote:
> 
> > On Thu, Nov 18, 2010 at 12:30:52AM +0900, Izumi Tsutsui wrote:
> 
> > > > What I ended up is pmap_mmap(9), which is exactly mmmmap(), but
> > > > made public.
> > > > 
> > > > Does this sound right?
> > > 
> > > Probably it's time to remove "mmap cookie" type as pmap(9) says
> > > since we have separate paddr_t and vaddr_t?
> > 
> > I'm all for rethinking the design from ground.
> 
> Yes, this needs to be carefully considered.  The "mmap cookie" is not 
> necessarily a PA.  On sparc64 it contains additional information that pmap 
> needs to know to successfully set up a correct TLB entry.  And some 
> machines, even modern ones, may not have linear physical address spaces.

Understood.  Like the ECC bits you mentioned.

> 
> > And my answer to this question is, bus_space_physload(9).
> 
> What's that do and how is that relevent to managed memory?

Managed memory has vm_pages.  Device driver looks up the vm_physseg
(and offset) from vm_pages (usually bus_dma(9) ones).  My point
is, by allocating vm_physseg for devices too, we can equally return
physical page identities.

I think cdevs can be easily converted, because there's a dedicated
udv_fault(), where we can easily pass the "mmap cookie" equivalent
to pmap_enter(9).

(XIP on kernel .data is much different, but this is another story.)

> 
> > cdev_mmap(9) will return "struct vm_physseg *" + "off_t", instead
> > of "mmap cookie".  The vm_physseg is either on device's MMIO page
> > or RAM.  I hope this will be understood.  Otherwise I have to do
> > so many hacks to achieve XIP... :(
> 
> I think that will break existing implementations.

Yes, it needs a new name, like cdev_page(9).

> 
> Eduardo

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635