Re: [Qemu-devel] [PATCH 4/4] qmp: add BLOCK_MEDIUM_EJECT event

[Markus Armbruster <armbru@redhat.com>]

Kevin Wolf <kwolf@redhat.com> writes:

> Am 16.02.2012 19:30, schrieb Markus Armbruster:
>> Let's figure out how this stuff really works.
>> 
>> 1. Guest load/eject
>> 
>> Guest commands load or eject.  Device model updates its state of virtual
>> tray (e.g. IDEState member tray_open) unless locked, then calls
>> bdrv_eject().
>> 
>> bdrv_eject() is a no-op except for pass-through backends such as
>> host_cdrom.
>> 
>> Note: device models call bdrv_eject() whether the state changed or not.
>> The only use for that I can see is syncing a wayward physical tray to
>> the virtual one.  Shouldn't be necessary with Paolo's recent work,
>> should it?
>
> The one case that I'm unsure about is migration. I thought we sync the
> physical tray with the virtual one then (or at least we discussed it),
> but I don't really know what we do today, or even what the right thing
> to do is in some cases.

I looked into this back when I moved tray stuff into device models.  I
believe it needs fixing, but my patch was flawed[*], so I shelved it.

Whether migration makes sense while the host CD-ROM is passed through is
a valid question.

>> I figure Luiz's patch works.  But maybe it could be simplified some by
>> replacing bdrv_dev_change_media_cb() by a "open/close tray" callback
>> that returns whether it moved.  bdrv_dev_change_media_cb() would then
>> simply open the tray, emit event if it moved, close the tray, emit event
>> if it moved.
>
> Yes, I had the same impression after reading the first few paragraphs of
> your analysis (which looks right to me).

If I understand Luiz correctly, he'd like to do that in a follow-up
patch.


[*] http://lists.nongnu.org/archive/html/qemu-devel/2011-09/msg00324.html