From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48112) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RyKSL-0005AT-SW for qemu-devel@nongnu.org; Fri, 17 Feb 2012 04:50:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RyKSG-0004Ky-Dz for qemu-devel@nongnu.org; Fri, 17 Feb 2012 04:50:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42431) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RyKSG-0004Kb-2D for qemu-devel@nongnu.org; Fri, 17 Feb 2012 04:50:16 -0500 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1H9oEMk005468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 17 Feb 2012 04:50:15 -0500 Message-ID: <4F3E239C.6050402@redhat.com> Date: Fri, 17 Feb 2012 10:53:32 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <1329331347-11232-1-git-send-email-lcapitulino@redhat.com> <1329331347-11232-5-git-send-email-lcapitulino@redhat.com> <20120216111447.2160fa63@doriath.home> <4F3D054C.9020603@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/4] qmp: add BLOCK_MEDIUM_EJECT event List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: pbonzini@redhat.com, eblake@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino Am 16.02.2012 19:30, schrieb Markus Armbruster: > Let's figure out how this stuff really works. > > 1. Guest load/eject > > Guest commands load or eject. Device model updates its state of virtual > tray (e.g. IDEState member tray_open) unless locked, then calls > bdrv_eject(). > > bdrv_eject() is a no-op except for pass-through backends such as > host_cdrom. > > Note: device models call bdrv_eject() whether the state changed or not. > The only use for that I can see is syncing a wayward physical tray to > the virtual one. Shouldn't be necessary with Paolo's recent work, > should it? The one case that I'm unsure about is migration. I thought we sync the physical tray with the virtual one then (or at least we discussed it), but I don't really know what we do today, or even what the right thing to do is in some cases. > I figure Luiz's patch works. But maybe it could be simplified some by > replacing bdrv_dev_change_media_cb() by a "open/close tray" callback > that returns whether it moved. bdrv_dev_change_media_cb() would then > simply open the tray, emit event if it moved, close the tray, emit event > if it moved. Yes, I had the same impression after reading the first few paragraphs of your analysis (which looks right to me). Kevin