Subject: Re: remplacing page mappings behind uvm
To: YAMAMOTO Takashi <firstname.lastname@example.org>
From: Manuel Bouyer <email@example.com>
Date: 12/01/2007 15:36:05
On Sat, Dec 01, 2007 at 11:27:11PM +0900, YAMAMOTO Takashi wrote:
> > On Sat, Dec 01, 2007 at 10:23:40PM +0900, YAMAMOTO Takashi wrote:
> > > i think the easiest fix for the problem which started this thread
> > > is making libxc (back) to use non-anonymous mapping.
> > > as far as you mmap a valid object (either kernfs file or device,
> > > i prefer the latter), uvm_unmap calls pmap_remove for you.
> > I agree that we should have a valid object (at last a valid map entry,
> > which, as things are now, probably means a valid object). But I'm not sure
> > at all that mmaping a device to get the object at mmap time rather than
> > ioctl time makes things easiers.
> it makes things easier because we don't need to make vm provide
> a functionality to replace existing vm entries.
I'm not sure we can avoid it
> > This doesn't fix the problems with the
> > ioctl,
> the problem with the ioctl is that it replaces the existing mapping.
> if you mmap the device, you can control the existing mapping.
> > and introduce some more issues (like, we can't provide physical
> > addresses to udv_attach() or udv_fault() because these are not physical
> > adresses, and we don't even have them at the time of mmap).
> as far as ioctl does pmap_enter_ma by itself, udv_fault implies
> an error of user.
But if the ioctl does pmap_enter_ma() by itself, the vm_map won't have
the appropriate infos, isn't it ? Especially, uvm won't known that
this range is really mapped, and I suspect accounting will be wrong.
> > --
> > Manuel Bouyer <firstname.lastname@example.org>
> > NetBSD: 26 ans d'experience feront toujours la difference
> > --
> i personally don't think it's worth to keep bug-to-bug compatibility for
> this. if it was for a linux-compatibility thing which we can't
> control, i can understand. but it's a netbsd specific interface.
For which we have existing binaries.
> it isn't the first time this interface is changed without keeping
> binary compatibility. (it's a little ironic that this "replace anonymous
> mapping" thing was introduced by the last change which didn't keep binary
AFAIK this interface didn't change since I got xentools working. Old
xentools20 should still work with netbsd-4, and even current if the pthread
issues can be worked around.
Manuel Bouyer <email@example.com>
NetBSD: 26 ans d'experience feront toujours la difference