[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: xmd(4) (Re: XIP)
On Thu, Oct 28, 2010 at 05:31:45AM +0000, YAMAMOTO Takashi wrote:
> > Here's the reason why I've written xmd_machdep.c:
> > xmd(4) is a read-only RAM-based disk driver capable of XIP. The
> > main purpose is to test XIP functionality. xmd(4) can be implemented
> > on any platforms that supports VM in theory. xmd(4) may be also
> > useful for other cases where md(4) is used, but users want to save
> > memory. md(4) allocates memory for its storage, and copies pages
> > from or to page cache.
> > xmd(4) allocates a static, read-only array and provides it as a
> > backing store. When it's used as XIP, it registers the array as
> > a physical device page segment. From VM's POV, the registered
> > region is seen like a ROM in a device connected over some buses.
> > The procedure to register an array as a physical segment is somewhat
> > strange. The registered array resides in kernel's read-only data
> > section. Kernel already maps its static region (text, rodata,
> > data, bss, ...) at boot time. xmd(4) "re-defines" part of it as
> > a physical device segment, like a ROM connected via another bus.
> > As far as the backing store array resides in main memory, you'll
> > end up with some way to convert kernel VA back to physical address.
> > There is no alternative to achieve the goal in MI way, or xmd.c is
> > sprinkled like mem.c.
> why can't you use pmap_extract?
Because looking up a paddr_t doesn't help alone.
The driver needs to allocate a physical segment object (struct
vm_physseg) and per-page objects (struct vm_page), so that its
region can be mapped to user address. This is done by calling
bus_space_physload_device() or xmd_machdep_physload(), which in
turn call uvm_page_physload_device().
This is what happens during a fault onto xmd:
- User opens a cdev (/dev/XXX), then calls mmap() with its fd
- User touch a mapped address
- Fault is triggered, fault handler looks up user's map and map
- uvm_fault() -> udv_fault() -> cdev_mmap() -> xmd_mmap()
- xmd_mmap() returns a "paddr_t"
- udv_fault() enters the paddr_t to pmap_enter()
- pmap_enter looks up a vm_physseg from a paddr_t
- pmap_enter looks up a vm_page from a vm_physseg
- pmap_enter looks up a vm_page_md from a vm_page
This is redundant. The problem is we use "paddr_t" as a cookie
to identify a page in a segment, overriding its original meaning,
physical address. What pmap_enter needs is an ID. Looking up a
physical address from an ID is easy. The reverse is not.
After these observations, I have concluded that any appearance of
"paddr_t" in any MI code (sys/uvm, sys/kern, sys/dev) is a wrong
approach. I don't see how pmap_extract() helps this situation?
> YAMAMOTO Takashi
> > Masao
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Main Index |
Thread Index |