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: Weidong Huang
Subject: Re: [Qemu-devel] Close the BlockDriverState when guest eject the media
Date: Tue, 21 Oct 2014 08:46:10 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1

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






reply via email to

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