From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgNaw-0002Qv-JW for qemu-devel@nongnu.org; Mon, 20 Oct 2014 20:46:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgNaq-0007z8-DC for qemu-devel@nongnu.org; Mon, 20 Oct 2014 20:46:38 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:23114) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgNap-0007y0-Pf for qemu-devel@nongnu.org; Mon, 20 Oct 2014 20:46:32 -0400 Message-ID: <5445ACD2.8000209@huawei.com> Date: Tue, 21 Oct 2014 08:46:10 +0800 From: Weidong Huang MIME-Version: 1.0 References: <54423AC9.2030302@huawei.com> <20141020094149.GC3585@noname.redhat.com> <5444F1B2.9090700@huawei.com> <20141020113947.GH3585@noname.redhat.com> In-Reply-To: <20141020113947.GH3585@noname.redhat.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Close the BlockDriverState when guest eject the media List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: "qemu-devel@nongnu.org" , stefanha@redhat.com, armbru@redhat.com On 2014/10/20 19:39, Kevin Wolf wrote: > Am 20.10.2014 um 13:27 hat Weidong Huang geschrieben: >> On 2014/10/20 17:41, Kevin Wolf wrote: >> >>> Am 18.10.2014 um 12:02 hat Weidong Huang geschrieben: >>>> Hi ALL: >>>> >>>> There are two ways to eject the cdrom tray. One is by the eject's qmp commmand(eject_device). >>>> The another one is by the guest(bdrv_eject). They have different results. >>> >>> Yes, they are different things. >>> >>> If a guest opens the tray (using bdrv_eject) and then closes it again, >>> with no user interaction in between, the virtual media must still be in >>> the drive and the guest must be able to access the same image again. >>> Calling bdrv_close() in this case would be a bug. >>> >>> The goal of the monitor command "eject" on the other hand is to remove >>> the medium so that the drive is empty. That a device with a closed tray >>> has to be opened for this is only secondary. >> >> >> Thanks for your reply. >> >> There is a problem. >> >> 1. Qemu receive the "eject" command. >> 2. Runs "eject_request_cb" when an eject request is issued from the monitor, the tray >> is closed, and the medium is locked. But the drive is not closed. >> 3. Guest agree with opening tray and qemu will call bdrv_eject to complete. The drive is >> still not close. >> >> So the result of the monitor command "eject" is not to remove the medium in this situation. > > Now I understand, thanks for explaining. > > But I think libvirt can actually work correctly with what qemu offers > today. qemu returns an error if the medium cannot be removed with the > 'eject' command and it only sends an eject request to the guest. > > With this error, libvirt can know that the DEVICE_TRAY_MOVED event > doesn't mean that the medium has removed, but that it needs to issue > another 'eject' command. > > If this isn't implemented correctly in libvirt today, this needs a > libvirt fix rather than a qemu one. > OK. Thanks. I will discuss it in libvirt community. >>>> eject_device: close the BlockDriverState(bdrv_close(bs)) >>>> bdrv_eject: don't close the BlockDriverState, >>>> >>>> This is ambiguous. So libvirt can't handle some situations. >>>> >>>> libvirt send eject qmp command ---> qemu send eject request to guest ---> >>>> guest respond to qemu ---> qemu emit tray_open event to libvirt ---> >>>> libvirt will not send change qmp command if media source is null. So >>>> the media is not be replace to the null. >>> >>> What is the problem that libvirt has with the guest opening the tray? I >>> don't think libvirt should even care about that case. >> >> >> For example, using libvirt to change media by xml below(media source is null): >> >> >> >> >> >> libivrt return ok. But media still is in the guest. >> This is confused. > > Kevin > > . >