[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: XIP (Rev. 2)
On Tue, Nov 09, 2010 at 03:18:37PM +0000, Eduardo Horvath wrote:
> On Tue, 9 Nov 2010, Masao Uebayashi wrote:
> > On Tue, Nov 09, 2010 at 07:28:34PM +1100, matthew green wrote:
> > >
> > > > I'll merge this in a few days. I believe I've given enough reasonings
> > > > to back this design in various places.
> > >
> > > do not do this.
> > >
> > > this code has currently seen review that was less than favourable
> > > and you have not given much consideration to the flaws. unless
> > What are the flaws?
> There are two issues I see with the design and I don't understand how
> they are addressed:
> 1) On machines where the cache is responsible for handling ECC, how do you
> prevent a user from trying to mount a device XIP, causing a data error and
> a system crash?
Sorry, I don't understand this situation... How does this differ
from user mapped RAM pages with ECC?
> 2) How will this work with mfs and memory disks where you really want to
> use XIP always but the pages are standard, managed RAM?
This is a good question. What you need to do is:
- Provide a block device interface (mount)
- Provide a vnode pager interface (page fault)
You'll allocate managed RAM pages in the memory disk driver, and
keep them. When a file is accessed, fault handler asks vnode pager
to give relevant pages back to it.
My current code assumes XIP backend is always a contiguous MMIO
device. Both physical address pages and metadata (vm_page) are
contiguous, we can look up matching vm_pages (genfs_getpages_xip).
If you want to use managed RAM pages, you need to manage a collection
of vm_pages, presented as a range. This is exactly what uvm_object
is for. I think it's natural that device drivers own uvm_object, and
return their pages back to other subsystems, or "loan" pages to
other uvm_objects like vnode. The problem is, the current I/O
subsystem and UVM are not integrated very well.
So, the answer is, you can't do that now, but it's a known problem.
(Extending uvm_object and using it everywhere is the way to go.)
Main Index |
Thread Index |