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

[Gonglei]

On 2014/10/21 13:53, Weidong Huang wrote:

> 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.
>>
> 
> 
> hi all!
> 
> How about fix it in libvirt?
> 

Cc'ing Eric for more attention.

Maybe He can give you some suggestion :)

Best regards,
-Gonglei

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