On Sat, Dec 01, 2007 at 04:46:42PM +0900, YAMAMOTO Takashi wrote:
> > > we can easily tweak the api.
> > 
> > This would mean changing all device's mmap functions, isn't ?
> 
> or introduce optional d_foo entry points.
> for the purpose of udv_attach, it's a little silly to call a driver for
> every single page frames.
> 
> as foreign pages can't be represented by paddr_t, some tricks are
> necessary for d_mmap+pmap_enter in udv_fault.

Yes, anyway. And worse, xpq_update_foreign() may fail, and the error has to
be reported back to the caller of IOCTL_PRIVCMD_MMAPBATCH. Without it
qemu-dm doesn't work, I ran into this while getting xentools3-hbm working
on amd64.

> 
> > I'd prefer to see support for custom mmap in /kern ...
> 
> why?

I suspect it would be usefull for some other /kern entries, and
limit the proliferation of /entries in /dev (xsd_kva is an example,
it's natural place would be /kern but needs mmap())

> 
> > Now that I'm thinking about it, it should be possible to create a
> > uvm_object backed mapping in the ioctl calls, isn't it ?
> 
> you can, but i think it's better to actually implement mmap.

I still feel it doesn't really match what Xen wants, and would require
hacks at last as big as what we have now. The main problems are 
1) at mmap time we don't have yet the domid and list of machine adresses
2) Xen wants to get back a list of pages that couldn't get mapped in
   the list it provided (mmap() on a device can't report this information,
   you have to use a ioctl anyway; and have the mapping occur at ioctl
   time to report back the errors).
3) Xen wants to change the mappings over time for a given range of VA.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--