On Thu, Oct 28, 2010 at 07:59:17AM +0000, YAMAMOTO Takashi wrote: > hi, > > > On Thu, Oct 28, 2010 at 05:31:45AM +0000, YAMAMOTO Takashi wrote: > >> hi, > >> > >> > 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 > > entry > > - 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? > > because you seem saying that there is no MI way to > "convert kernel VA back to physical address", i suggested > pmap_extract. i guess i don't understand your situation. :-)
I come to think that pmap_extract(9) API is unnecessary at all. See other mails for the details... Masao > > YAMAMOTO Takashi > > > > > Masao > > > >> > >> YAMAMOTO Takashi > >> > >> > > >> > Masao > > > > -- > > Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635 -- Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
