On Tue, Oct 19, 2010 at 09:32:29AM -0500, Ryan Harper wrote: > Block hot unplug is racy since the guest is required to acknowlege the ACPI > unplug event; this may not happen synchronously with the device removal > command > > This series aims to close a gap where by mgmt applications that assume the > block resource has been removed without confirming that the guest has > acknowledged the removal may re-assign the underlying device to a second guest > leading to data leakage. > > This series introduces a new montor command to decouple asynchornous device > removal from restricting guest access to a block device. We do this by > creating > a new monitor command drive_unplug which maps to a bdrv_unplug() command which > does a qemu_aio_flush; bdrv_flush() and bdrv_close(). Once complete, > subsequent > IO is rejected from the device and the guest will get IO errors but continue > to > function. > > A subsequent device removal command can be issued to remove the device, to > which > the guest may or maynot respond, but as long as the unplugged bit is set, no > IO > will be sumbitted.
The name 'drive_unplug' suggests to me that the drive object is not being deleted/free()d ? Is that correct understanding, and if so, what is responsible for finally free()ing the drive backend ? Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
