[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
On Fri, Mar 26, 2010 at 04:25:19PM +0000, Eduardo Horvath wrote:
> On Fri, 26 Mar 2010, Masao Uebayashi wrote:
> > This is the list of updated functions:
> > /* register device memory as part of system memory */
> > void *bus_space_physload(bus_space_tag_t space, bus_addr_t addr,
> > bus_size_t size);
> > void bus_space_physunload(void *physseg);
> > /* register device region as user-mappable managed region */
> > void *bus_space_physload_device(bus_space_tag_t space, bus_addr_t addr,
> > bus_size_t size, int prot, int flags);
> > void bus_space_physunload_device(void *physseg);
> > I've not considered the "memory" one very much. It needs more thought...
> I'm not convinced that handing device pages off to the VM subsystem is the
> correct approcach. That makes the assumption that all physical address
> space is equivalent and you don't have to worry about caches or
> sideffects, which the MMU needs to be informed about in some architectures
> or you get all sorts of nasty effects such as data corruption or data
The point is that device drivers call bus_space_physload_device(9) only for
regions that are potentically mapped as cache enabled or other effects. In
that case the registered regions are treated as "managed"; UVM allocates a
"context" to keep track of where pages are mapped and how. pmap(9) keeps a
state in struct vm_page_md (conventionally). So UVM will allocate struct
vm_page_md "hash" to manage only mapped pages.
I assume device regions have uniform charasteristic. (I'm looking for a
> I think a better design woult be to have the device driver provide a
> routine UVM calls to enter and remove individual pages from the pmap.
> That way you can do device or specific things such as setting the
> non-cacheable or write-only bit on the TTE.
Do you mean you expose MMU knowledge to device drivers? How does your idea
look in pseudo code?
I don't want to give device drivers too much freedom. Real devices are
connected via buses. It's odd that those drivers have to know things beyond
those physical connections.
(I'll learn TTE then reply again.)
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Main Index |
Thread Index |