Subject: Re: remplacing page mappings behind uvm
To: YAMAMOTO Takashi <firstname.lastname@example.org>
From: Manuel Bouyer <email@example.com>
Date: 12/01/2007 16:22:37
On Sun, Dec 02, 2007 at 12:03:15AM +0900, YAMAMOTO Takashi wrote:
> > > > 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.
> which accounting are you talking about?
> basically uvm doesn't track mapping of individual pages.
> pmap does, but it's MD and under your control.
Doesn't it have a uvm_page for each page in the (user) pmap, even thoses
backed by an uvm_object ?
> > > 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
> > > compatibility.)
> > 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.
> it depends on how old "old xentools20" is. see UPDATING rev.1.140.
But it was in current, not in a release branch.
Manuel Bouyer <firstname.lastname@example.org>
NetBSD: 26 ans d'experience feront toujours la difference