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