earlier remove the backend of tapdisk device in xenstore to release the resource allocated in backe

Blktapctl thread will use qemu-dm connection instead of tapdisk-ioemu in thecase of FV VM. We found the resource like memory allocated for this Guestcan't be free for backend driver couldn't be closed in qemu-dm. This patch would  remove the backend of tapdisk device earlier in xenstoreto triger qemu-dm to notify the backend driver to release the resourceallocated.I have tested this patch at the case of1, save && restore 2, destory && shutdown3, snapshotregards,-James (Song Wei)

http://xen.1045712.n5.nabble.com/attachment/2546045/0/wait_for_tapdisk_close.diff

The cleanup done here is to close open file handles 
and/or mmap-s associated with blktap. You may have seen the kernel 
side patches to allow the system as a whole to recover from that 
state (particularly when qemu-dm crashes), but in general I consider 
it bad practice for an application to keep open huge amounts of 
mapped memory when getting orderly terminated. 

"Orderly" in the qemu-dm case unfortunately means being terminated 
by a signal, hence the signal should be intercepted by qemu 
(otherwise, i.e. in the current state) the design seems broken to me. 

Having said that doesn't mean that I agree to the blktap-centric 
approach taken by the patch. Imo global cleanup should be 
performed by qemu-dm upon being terminated - the question just is 
whether such code already exists (and just needs to be hooked up), 
or whether that part is missing altogether and needs to be written 
from scratch. 

The bug was with the blktap kernel driver not being able to clean up after an unclean exit of qemu. We had reports of this only for 3.4 and 4.0 (and I wonder how no-one else noticed this, when the bug was introduced about a year ago, even before blktap2 got added), yet the problematic blktap code also existed in those systems that we ship with 3.2.3 and 3.3.1, hence either no-one ever noticed the problem on those platforms, or there must be a behavioral difference of qemu (i.e. cleaning up after itself in earlier versions). I fully agree that the kernel should (or really has to) properly clean up after any uncleanly exiting application, yet ... 

http://xen.1045712.n5.nabble.com/PATCH-2-2-reap-the-blktapctl-thread-and-notify-the-tapdisk-backend-driver-to-release-resource-like-m-td2546045.html

http://xen.1045712.n5.nabble.com/PATCH-1-2-reap-the-blktapctl-thread-and-notify-the-tapdisk-backend-driver-to-release-resource-like-m-td2545839.html

http://xen.1045712.n5.nabble.com/PATCH-2-2-reap-the-blktapctl-thread-and-notify-the-tapdisk-backend-driver-to-release-resource-like-m-td2546045.html