From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55575) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RqkWI-0004Ym-4i for qemu-devel@nongnu.org; Fri, 27 Jan 2012 07:03:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RqkWD-0000pX-U3 for qemu-devel@nongnu.org; Fri, 27 Jan 2012 07:03:06 -0500 Received: from mail-qy0-f173.google.com ([209.85.216.173]:42069) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RqkWD-0000pN-QI for qemu-devel@nongnu.org; Fri, 27 Jan 2012 07:03:01 -0500 Received: by qcse13 with SMTP id e13so895499qcs.4 for ; Fri, 27 Jan 2012 04:03:01 -0800 (PST) Sender: Paolo Bonzini Message-ID: <4F22926D.10503@redhat.com> Date: Fri, 27 Jan 2012 13:02:53 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <20120124161628.4bf2592c@doriath.home> <4F1F0E9F.8080302@redhat.com> <4F1FC030.2030705@redhat.com> <20120125104204.55eec0a1@doriath.home> <20120126155757.3e97a0c1@doriath.home> <4F2273CF.3050107@redhat.com> In-Reply-To: <4F2273CF.3050107@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Markus Armbruster , Eric Blake , qemu-devel , Luiz Capitulino On 01/27/2012 10:52 AM, Kevin Wolf wrote: >> > Conclusion: eject returned an error, but a few seconds later the tray opened and >> > the media wasn't purged. What happened here is that, the_guest_ >> > opened the tray. The code in this patch would trigger the event, but >> > we shouldn't emit it twice if we cover eject& change (ie. special case) > bdrv_dev_change_media_cb is not called because media cannot be ejected > with a locked drive. Instead bdrv_dev_eject_request is called which > doesn't emit an event. > > If the guest happens to initiate an eject itself after receiving the > eject request, it calls bdrv_eject, where we can emit an event. > > If we had force=true in the initial eject command, bdrv_close is called, > which in turn goes through bdrv_dev_change_media_cb where an event is > emitted. But we still emit the eject request, and the guest will cause bdrv_eject to raise the event again. There can always be a race with the guest setting the locked bit, so management has to do a query-block anyway after eject or change. That's why the event is not necessary when the eject is host-initiated. Paolo