Re: Device page

[Matt Thomas <matt%3am-software.com@localhost>]

On Feb 2, 2010, at 4:13 PM, YAMAMOTO Takashi wrote:

>> On Feb 2, 2010, at 10:20 AM, Masao Uebayashi wrote:
>> 
>>> As I briefly mentioned before, I'll need device page to support XIP.  It's
>>> a struct vm_page *, which is actually a magic value which conveys data from
>>> pgo_get() to pmap_enter().
>>> 
>>> When a device page is pmap_enter()'ed, pmap checks if it's a device page or
>>> not, if so, stores a PV into a dedicated vm_physseg for devices.  When a
>>> device page is passed to pmap_page_*() (struct vm_page *-oriented 
>>> functions),
>>> they look for the device vm_physseg, look up a PV header, then look up a PV.
>>> 
>>> I also want to make these minimal PV handling moved to some MI place - 
>>> probably
>>> uvm_page.c.  Now we don't define MI PV header yet, I'll allocate struct
>>> vm_page_md *[] for each XIP-capable device.  This will be put in uvm_page.c
>>> too.
>> 
>> I'd rather change the arguments to pmap_{zero,copy}_page from paddr_t to 
>> struct vm_page * since it's easier to fetch the physical address from the 
>> page than getting the vm_page from the pa.
> 
> recording physical adderess in each vm_page wastes space given that vm_page
> is allocated as an array.
> ie. if we have a way to find the corresponding physseg from a vm_page,
> its corresponding physical address can be calculated.
> so i hesitate to propagate the assumption of fast VM_PAGE_TO_PHYS.

I'd also like to see UVM/pmap use a pfn_t (physical/page frame number) instead 
of paddr_t.  That would allow most ports to return to using 32bit for that 
type.  (for a 4K page, a 32 bit PFN would be usable for up to 16TB of physical 
address space - more than enough for now).