On Sat, Dec 01, 2007 at 12:12:56AM +0900, YAMAMOTO Takashi wrote:
> > On Fri, Nov 30, 2007 at 10:11:14PM +0900, YAMAMOTO Takashi wrote:
> > > > 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.
> > > 
> > > iirc we used to mmap privcmd to allocate va range.
> > 
> > No, I don't remember it ever being this way. And there's no mmap-related
> > patches in xentools3-hvm ..
> > 
> > -- 
> > Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
> >      NetBSD: 26 ans d'experience feront toujours la difference
> > --
> 
> RCS file: /cvsroot/pkgsrc/sysutils/xentools20/patches/patch-as,v
> 
> ----------------------------
> revision 1.1
> date: 2005/05/23 22:02:04;  author: bouyer;  state: Exp;
> branches:  1.1.2;
> Don't mmap /kern/xen/privcmd (this doesn't work any more on current), use
> MAP_ANON instead. Bump pkgrevision.
> ----------------------------

But this is Xen2, not Xen3 ... I think this was in a different context, not
related to the IOCTL_PRIVCMD_MMAP* ioctls.

In xen3, this happens in libxc/xc_netbsd.c. We have to implement a
xc_map_foreign_range() function, which has to map memory from a remote
domain over an existing VA range. xc_map_foreign_range() doesn't allocate
the VA space itself (eventually the same VA range will be remapped several
times).

I suspect this is exported to python ...

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