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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> "James (song wei)" <jsong@xxxxxxxxxx> 22.04.10 10:08 >>>
>--- a/tools/python/xen/xend/XendDomainInfo.py   Mon Apr 19 17:57:28 2010 +0100
>+++ b/tools/python/xen/xend/XendDomainInfo.py   Thu Apr 22 15:54:01 2010 +0800
>@@ -2406,8 +2406,13 @@
>
>     def _releaseDevices(self, suspend = False):
>         """Release all domain's devices.  Nothrow guarantee."""
>+        t = xstransact("%s/device" % self.vmpath)
>         if self.image:
>             try:
>+                for dev in t.list('tap'):
>+                    log.debug("Early removing %s", dev);
>+                    self.getDeviceController('tap').destroyDevice(dev, True)
>+                time.sleep(0.1)
>                 log.debug("Destroying device model")
>                 self.image.destroyDeviceModel()
>             except Exception, e:
>@@ -2416,9 +2421,10 @@
>             log.debug("No device model")
>
>         log.debug("Releasing devices")
>-        t = xstransact("%s/device" % self.vmpath)
>         try:
>             for devclass in XendDevices.valid_devices():
>+                if devclass is 'tap':
>+                    continue
>                 for dev in t.list(devclass):
>                     try:
>                         log.debug("Removing %s", dev);
                                                                  
This seems more like a hack than a solution: Surely qemu-dm gets
sent some sort of signal to shut down and clean up. The question
thus really is why that cleanup doesn't include cleaning up blktap
related resources. That is, I would expect the fix to be in qemu-dm,
or at most in the xend code that reaps qemu-dm.

More generally any solution should be generic, or it should be
explained properly why the device class needs treatment
different from any of the other ones (and, for this specific
case, why moving the device destruction a little ahead will
now *guarantee* that the cleanup can happen as expected).

Jan


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