> On Sat, Dec 01, 2007 at 01:05:27AM +0900, YAMAMOTO Takashi wrote:
> > > > 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.
> > 
> > they are for IOCTL_PRIVCMD_MMAPBATCH/IOCTL_PRIVCMD_MMAP.
> 
> Yes, but in Xen2. They're not used in exactly the same way in Xen3.

can you explain how differently they are used?
it seems quite similar to me.

> > > 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 ...
> > 
> > libxc mmap /proc/xen/privcmd for linux.
> 
> But this doesn't helps us, because it's mmapped before calling
> IOCTL_PRIVCMD_MMAP*. AFAIK we have to return a valid page address at the
> time a device mmap callback is called.

are you talking about d_mmap calls in udv_attach?
we can easily tweak the api.

YAMAMOTO Takashi