Re: [Xen-devel] The hypercall will fail and return EFAULT when the page becomes COW by forking process in linux

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2012-07-03 at 13:08 +0100, Wangzhenguo wrote:
> > On Mon, 2012-07-02 at 07:40 +0100, Wangzhenguo wrote:
> > > Hi, everybody
> > >     I meet a trouble. in dom0, I call the xc_domain_set_pod_target
> > hypercall in one thread, and meanwhile fork a process in another thread,
> > it will return EFAULT by the function of copy_to_user failed in
> > hypervisor. I see that when forking a process, the page will become COW,
> > copy_to_user will cause a wirte protection page fault and return EFAULT.
> > >     Is There any ideas for it?
> > 
> > You must lock down any memory to be used as a hypercall argument.
> > 
> > libxc provides the xc_hypercall_buffer interfaces specifically for this
> > reason.
> > 
> > Also in general you should be using libxc instead of open coding your
> > own hypercalls. In this case xc_domain_get_pod_target() is the function
> > to use.
> 
> Thanks for your reply. Yes, I use the libxl coding in my program(The
> simple code is just for emulating the COW page). The following is the
> context that causes the EFAULT error. There are many threads in my
> program, one thread(thread1) calls the  libxl_set_memory_target to set
> pod, another thread(thread2) calls fork at between the t2 and t3 time.
> After fork, all pages are COW in the program. And I think any get
> operation hypercalls will fail when another thread calls fork at
> between the t2 and t3 time.
> 
> time  thread1                            thread2
>        |                                  |
>  t0:call libxl_set_memory_target(libxl)   |
>        |                                  |
>  t1: xc_domain_set_pod_target(libxc)      |    
>        |                                  |         
>  t2: do_xen_hypercall(privcmd)            |
>        |                                 fork
>  t3: __HYPERVISOR_memory_op               |
>        |                                  |
>  t4: return EFAULT
>        |
> > 

Hrm. yes. This basically harks back to the use of mlock as a surrogate
for the requirement to properly lock down memory for use as a hypercall
argument. This is flawed in ways other than this (i.e. NUMA memory
migration would also break it).

The correct answer here is a special device (e.g. /dev/xen/hypercall?)
which can be mmap by libxc to provide memory specifically for this
purspoe which is fully locked down (e.g. VM_DONTCOPY and whatever else
is required).

The libxc "osdep" interface (see xenctrlosdep.h) provides a framework
for doing this, it just doesn't actually implement the use of the
special driver yet.

Is that something you might be interested in coding up?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel