Subject: Re: remplacing page mappings behind uvm
To: None <email@example.com>
From: YAMAMOTO Takashi <firstname.lastname@example.org>
Date: 12/01/2007 22:40:04
> > is this uvm_map_pageable only for debug?
> No, it's because we need to enter the mappings *now*, to be able to
> report mappings that failed back to the ioctl caller.
hm, i didn't know that.
> > why do checkprot here?
> To know if the va range was mapped read-only or read-write. Is there some
> other way to get it ?
why bother to check it?
> > please don't use uvm_unmap_remove and uvm_unmap_detach here.
> > they are uvm-internal.
> What would you suggect to use instead here ?
uvm_unmap without checkprot. but see below.
> > besides, normally uvm_unmap_detach should not be used with the map locked.
> > (it's the main reason why it's separated from uvm_unmap_remove.)
> OK, that's easy :)
> > if the process is multithreaded (is xentools multithreaded?),
> xentools is multithreaded, but I don't think this interface is going to
> be used from multiple threads.
another thread does not need to use this interface.
calling mmap is enough to interfere us.
> > you need to replace the mapping atomically.
> > othewise the va range can be taken by another thread while we unmap it.
> > uvm_map_replace does something similar, but it doesn't deal with
> > arbitrary existing mappings.
i don't think it can be done without touching uvm internals currently.
probably uvm_map can obtain a "replace existing mapping" flag.
but i don't think it's worth to have. i realy think it's better to fix
the broken "replace anonymous mmap" interface.