Re: [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_MEDIUM_CHANGED

[Paolo Bonzini <pbonzini@redhat.com>]

On 02/10/2012 06:55 PM, Kevin Wolf wrote:
> Am 10.02.2012 18:04, schrieb Luiz Capitulino:
>> This reminds me about an earlier try where I did the following, iirc:
>>
>>  1. added commands blockdev-tray-open, blockdev-tray-close, blockdev-medium-insert,
>>     blockdev-medium-remove

I think this slightly overengineering.  eject and change work well 
enough, we do not need blockdev-medium-insert and blockdev-medium-remove 
(yet).  Of course there can be a new API, just nothing user-visible.

>>  2. added the events: BLOCK_TRAY_OPEN, BLOCK_TRAY_CLOSE, BLOCK_MEDIUM_INSERTED
>>     BLOCK_MEDIUM_REMOVED, which would be emitted when the relating command is issued
>>     (maybe the events could just be BLOCK_TRAY_CHANGED & BLOCK_MEDIUM_CHANGED)

Or even just one event with two boolean arguments.

Looks slightly less clean, but it has an advantage: a guest that sends 
"eject" can wait for an event and will know whether the eject command 
was really executed (tray = open, medium = none) or just an eject 
request was obeyed by the guest (tray = open, medium = present).

>> Now, maybe the guest eject could also emit BLOCK_TRAY_OPEN & BLOCK_TRAY_CLOSE. Then
>> I think this is a complete solution.

Yes.

> Looks good to me in general. I'm not sure how you're imagining to
> implement this, I would prefer not to emit events from the device code,
> but only from block.c.

... and yes. :)

> Another interesting point is what to do with host CD-ROM passthrough. I
> think the TRAY_OPEN/CLOSE part is doable (do Paolo's patches actually do
> that, so that we just need to add an event?).

It is in the part that I haven't posted yet.

> We would have to fake
> MEDIUM_REMOVED/INSERTED immediately before a TRAY_CLOSE if the medium
> has changed.

Not sure about this, the "medium" hasn't changed in the sense that the 
backend is still the same.

With passthrough, eject could become a synonym of tray-open.  It is very 
unintuitive that the device is completely disconnected by the backend. 
And with passthrough, as soon as the guest ejects my CD I know that I 
have to remove the medium before the guest reboots.  In other words we 
can expect some kind of collaboration from the user.

> LOCK/UNLOCK (which you forgot in your list) is only
> initiated by the guest or monitor (eject -f), so there's nothing special
> with passthrough.

Well, there are a couple of places where we unlock without calling 
bdrv_lock_medium, those should be fixed so that in the passthrough case 
we force-unlock the host CD too.

Paolo