Kevin Wolf <kw...@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
