qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Weidong Huang <hwd@huawei.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	stefanha@redhat.com, armbru@redhat.com
Subject: Re: [Qemu-devel] Close the BlockDriverState when guest eject the media
Date: Mon, 20 Oct 2014 11:41:49 +0200	[thread overview]
Message-ID: <20141020094149.GC3585@noname.redhat.com> (raw)
In-Reply-To: <54423AC9.2030302@huawei.com>

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.

> 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.

Kevin

> So close the BlockDriverState in bdrv_eject. Thanks.
> 
> diff --git a/block.c b/block.c
> index d3aebeb..0be69de 100644
> --- a/block.c
> +++ b/block.c
> @@ -5276,6 +5276,10 @@ void bdrv_eject(BlockDriverState *bs, bool eject_flag)
>          qapi_event_send_device_tray_moved(bdrv_get_device_name(bs),
>                                            eject_flag, &error_abort);
>      }
> +
> +    if (eject_flag) {
> +        bdrv_close(bs);
> +    }
>  }
> 

  reply	other threads:[~2014-10-20  9:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-18 10:02 [Qemu-devel] Close the BlockDriverState when guest eject the media Weidong Huang
2014-10-20  9:41 ` Kevin Wolf [this message]
2014-10-20 11:27   ` Weidong Huang
2014-10-20 11:39     ` Kevin Wolf
2014-10-21  0:46       ` Weidong Huang
2014-10-21  5:53       ` Weidong Huang
2014-10-21  6:10         ` Gonglei
2014-10-24 18:32           ` Eric Blake
2014-10-27  8:21             ` Markus Armbruster
2014-10-20 12:12     ` Markus Armbruster
2014-10-21  5:06       ` Weidong Huang
2014-10-21  8:33         ` Markus Armbruster
2014-10-21  9:17           ` Gonglei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141020094149.GC3585@noname.redhat.com \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=hwd@huawei.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).