Re: xmd(4) (Re: XIP)

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

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. :-)

YAMAMOTO Takashi

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