[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] earlier remove the backend of tapdisk device in xenstore to release the resource allocated in backend driver lies in dom0'kernel


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: "James (song wei)" <jsong@xxxxxxxxxx>
  • Date: Thu, 22 Apr 2010 18:48:56 -0700 (PDT)
  • Delivery-date: Thu, 22 Apr 2010 18:49:54 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>



Jim Fehlig wrote:
> 
>>Agreed.  qemu-dm should clean up these resources on shutdown.  AFAICT,
>>it currently relies on receiving CTRMSG_CLOSE from blktapctrl (see
>>ioemu-dir/hw/xen_blktap.c), which it may never receive before exiting.
> 
> No, I don't think so. The root cause in this issue is qemu-dm exit too
> earlier.  
> Qemu-dm has been destroyed before blktapctrl send "CTRMSG_CLOSE",
> moreover, removing the backend node in xenstore trigers the callback in
> blktapctrl to send "CTRMSG_CLOSE".  
> It's xend to decide who ought to be occured earlier between sending SIGHUP
> to qemu-dm and removing the backend node in xenstore.  Obviously, xend is
> the role of manager. So I think fix this issue in xend is appropriate.
> In addition,  If we really want to fix it in qemu, we have to intercept
> the exit signal sent by kill() in xend. I don't think intercept this
> singal in qemu for this point is proper.
> 
> -Jame (Song Wei)
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 

-- 
View this message in context: 
http://old.nabble.com/earlier-remove-the-backend-of-tapdisk-device-in-xenstore-to-release-the-resource-allocated-in-backend-driver-lies-in-dom0%27kernel-tp28325456p28336546.html
Sent from the Xen - Dev mailing list archive at Nabble.com.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.