Subject: Re: remplacing page mappings behind uvm
To: YAMAMOTO Takashi <firstname.lastname@example.org>
From: Manuel Bouyer <email@example.com>
Date: 11/30/2007 16:32:14
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
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