On Fri, Nov 30, 2007 at 09:34:05PM +0900, YAMAMOTO Takashi wrote:
> > On Fri, Nov 30, 2007 at 09:08:39PM +0900, YAMAMOTO Takashi wrote:
> > > > On Fri, Nov 30, 2007 at 12:31:06PM +0900, YAMAMOTO Takashi wrote:
> > > > > > Although it'a gross hack, it works for Xeni386. It also works on Xenamd64,
> > > > > > up to process exit: it triggers an assersion in pmap_destroy() because
> > > > > > pmap_remove() is not called on the hacked memory ranges.
> > > > > 
> > > > > how about tweaking device pager instead of maintaining these hacks?
> > > > 
> > > > I did look at this when I implemented these ioctls. It's not so easy.
> > > > mmap() on devices will use offsets, but the physical pages are not contigous,
> > > > yet xen wants them mapped as a contigous VM area. It can be done but would
> > > > mean a driver more complex than the simple ioctl I have now,
> > > 
> > > isn't an array enough to convert offset -> machine address?
> > 
> > No, because machine addresses are not contigous, but xen wants a contigous
> > virtual adresses. Also, you have to pass a domain id in some way
> 
> i meant something like:
> 	array[(va - start_va) >> PAGE_SIZE].maddr

Yes, so we have to keep a translation table, with an ioctl to populate it.
Then we have to change xen sources to deal with it, and it may not be so
easy because what it does now is the other way round: first get a
chunk of VM space, and then populate it, eventually not in one operation.

> 
> > > i'm not sure if it's a good idea to make vm deal with it
> > > in order to simplify this very uncommon driver.
> > 
> > pmap_enter_ma() is also used in other places.
> 
> what i don't like is the design which overwrites existing unrelated mappings.
> not pmap_enter_ma itself.


Sure. But I'm not the author of the design :)

-- 
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
     NetBSD: 26 ans d'experience feront toujours la difference
--