qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Close the BlockDriverState when guest eject the media


From: Markus Armbruster
Subject: Re: [Qemu-devel] Close the BlockDriverState when guest eject the media
Date: Mon, 20 Oct 2014 14:12:24 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Weidong Huang <address@hidden> writes:

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

Yes, callback eject_request_cb() runs "when an eject request is issued
from the monitor, the tray * is closed, and the medium is locked"
(quoting block.h).

> 3. Guest agree with opening tray and qemu will call bdrv_eject to
> complete. The drive is
> still not close.

Yes, the guest honors the request by unlocking and opening the tray.
This calls bdrv_lock_medium(), then bdrv_eject().

> So the result of the monitor command "eject" is not to remove the
> medium in this situation.

Correct.  This is a known wart.  To work around it, wait for event
DEVICE_TRAY_MOVED and eject again.  Yes, this is racy: the guest can
reclose the tray and lock it before you get your eject in.

Your patch removes this wart, but regresses other scenarios:

commit 4be9762adb0947a353e6efef2fed354f69218bfb
Author: Markus Armbruster <address@hidden>
Date:   Tue Jul 27 14:02:01 2010 +0200

    block: Change bdrv_eject() not to drop the image
    
    bdrv_eject() gets called when a device model opens or closes the tray.
    
    If the block driver implements method bdrv_eject(), that method gets
    called.  Drivers host_cdrom implements it, and it opens and closes the
    physical tray, and nothing else.  When a device model opens, then
    closes the tray, media changes only if the user actively changes the
    physical media while the tray is open.  This is matches how physical
    hardware behaves.
    
    If the block driver doesn't implement method bdrv_eject(), we do
    something quite different: opening the tray severs the connection to
    the image by calling bdrv_close(), and closing the tray does nothing.
    When the device model opens, then closes the tray, media is gone,
    unless the user actively inserts another one while the tray is open,
    with a suitable change command in the monitor.  This isn't how
    physical hardware behaves.  Rather inconvenient when programs
    "helpfully" eject media to give you a chance to change it.  The way
    bdrv_eject() behaves here turns that chance into a must, which is not
    what these programs or their users expect.
    
    Change the default action not to call bdrv_close().  Instead, note the
    tray status in new BlockDriverState member tray_open.  Use it in
    bdrv_is_inserted().
    
    Arguably, the device models should keep track of tray status
    themselves.  But this is less invasive.
    
    Signed-off-by: Markus Armbruster <address@hidden>
    Signed-off-by: Kevin Wolf <address@hidden>

Programs really depend on "eject, load, get the same medium back"
behavior.  Example: https://bugzilla.redhat.com/show_bug.cgi?id=558256
    
We intend to provide new commands that behave better than "eject".
Don't hold your breath.

>>> 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):
> <disk type='file' device='cdrom'>
>     <driver name='qemu'/>
>     <target dev='hdb' bus='ide'/>
> </disk>
>
> libivrt return ok. But media still is in the guest.
> This is confused.

libvirt bug, caused by the bad QEMU interface.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]