> > 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.

YAMAMOTO Takashi