From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56629) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVM6X-0000MY-Gr for qemu-devel@nongnu.org; Wed, 02 Apr 2014 10:25:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WVM6O-0005I2-Dl for qemu-devel@nongnu.org; Wed, 02 Apr 2014 10:25:25 -0400 Received: from e06smtp13.uk.ibm.com ([195.75.94.109]:59134) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WVM6O-0005Gu-5W for qemu-devel@nongnu.org; Wed, 02 Apr 2014 10:25:16 -0400 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 Apr 2014 15:25:14 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id ECBB71B0804B for ; Wed, 2 Apr 2014 15:25:06 +0100 (BST) Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by b06cxnps3075.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s32EOxLO64880894 for ; Wed, 2 Apr 2014 14:24:59 GMT Received: from d06av04.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s32EPABP010801 for ; Wed, 2 Apr 2014 08:25:10 -0600 Message-ID: <533C1DC5.6050605@linux.vnet.ibm.com> Date: Wed, 02 Apr 2014 16:25:09 +0200 From: Heinz Graalfs MIME-Version: 1.0 References: <1396360537-12520-1-git-send-email-graalfs@linux.vnet.ibm.com> <87eh1h8304.fsf@blackfin.pond.sub.org> In-Reply-To: <87eh1h8304.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] drive_del vs. device_del: what should come first? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org On 01/04/14 17:48, Markus Armbruster wrote: > Heinz Graalfs writes: > >> Hi Kevin, >> >> doing a >> >> virsh detach-device ... >> >> ends up in the following QEMU monitor commands: >> >> 1. device_del ... >> 2. drive_del ... >> >> qmp_device_del() performs the device unplug path. >> In case of a block device do_drive_del() tries to >> prevent further IO against the host device. >> >> However, bdrv_find() during drive_del() results in >> an error, because the device is already gone. Due to >> this error all the bdrv_xxx calls to quiesce the block >> driver as well as all other processing is skipped. >> >> Is the sequence that libvirt triggers OK? >> Shouldn't drive_del be executed first? > > No. OK, I see. The drive is deleted implicitly (release_drive()). Doing a device_del() requires another drive_add() AND device_add(). (Doing just a device_add() complains about the missing drive. A subsequent info qtree lets QEMU abort.) > > drive_del is nasty. Its purpose is to revoke access to an image even > when the guest refuses to cooperate. To the guest, this looks like > hardware failure. Deleting a device during active IO is nasty and it should look like a hardware failure. I would expect lots of errors. > > If you drive_del before device_del, even a perfectly well-behaved guest > guest is exposed to a terminally broken device between drive_del and > completion of unplug. The early drive_del() would mean that no further IO would be possible. > > Always try a device_del first, and only if that does not complete within > reasonable time, and you absolutely must revoke access to the image, > then whack it over the head with drive_del. What is this reasonable time? On 390 we experience problems (QEMU abort) when asynch block IO completes and the virtqueues are already gone. I suppose the bdrv_drain_all() in bdrv_close() is a little late. I don't see such problems with an early bdrv_drain_all() (drive_del) and an unplug (device_del) afterwards. >