Paolo Bonzini <pbonz...@redhat.com> writes: > On 02/10/2012 01:49 PM, Markus Armbruster wrote: >> With manage_door off: >> >> * cdrom_lock_medium() does nothing. Thus, guest OS operating the >> virtual door lock does not affect the physical door. >> >> * cdrom_eject() does nothing. Thus, guest OS moving the virtual tray >> does not affect the physical tray. > > That's because manage_door off means "we couldn't get O_EXCL to > work". udev will affect the physical tray and we cannot really compete > with it.
Understood. I'm just describing behavior to make sure I understand your patch, not criticizing it. >> Compare to before this patch: >> >> * cdrom_lock_medium() fails silently. Thus, guest OS operating the >> virtual door may or may not affect the physical door. It usually does >> unless the CD-ROM is mounted in the host. >> >> * cdrom_eject() perror()s when it fails. Thus, guest OS moving the >> virtual tray may or may not affect the physocal tray. It usually does >> unless the CD-ROM is mounted in the host, or udev got its paws on it >> (I think). >> >> With manage_door on: >> >> * cdrom_lock_medium() works exactly as before, except the common failure >> mode "CD-ROM is mounted in the host" can't happen. >> >> * cdrom_eject() works exactly as before, except the common failure mode >> "CD-ROM is mounted in the host" can't happen. >> >> Is this correct? >> >> If yes, is it what we want? > > For virtio-scsi+scsi-block, we definitely want O_EXCL to remove the > device from udev and the in-kernel poller. That's because GESN > reports events only once, and we do not want the host and guest to > race on receiving events. But in order to open with O_EXCL we need to > unmount (GNOME3 doesn't have an unmount menu item anymore, which is > why I did it myself in patch 5/5). Program A unmounting a filesystem that some unknown program B mounted for its own unknown reasons doesn't feel right to me. Even when program B sucks as badly as Gnome appears to do. Especially when program A does it automatically, silently, and without a way to switch it off. > For IDE we do not need O_EXCL in principle. However, using the > emulated passthrough CD-ROM gets confusing without O_EXCL (to the user > and to the guest, always; and sometimes, to the host udev as well). > Basically, the guest tries to lock the disk, but udev runs as root so > it can unlock it under its feet as soon as you press the button. With > O_EXCL and some extra patches (waiting for Luiz's eject event > discussion), everything kinda works; still confusing to the user, but > not to the host or VM. > > I have some prototype patches to improve the situation on IDE somehow > (still a far cry from scsi-block), but I'm waiting for Luiz's eject > event patches to reach a conclusion first. > > There is also the case of emulated passthrough SCSI CD-ROM, but I > don't care much about it. > >> Shouldn't the user be able to ask for one >> of "grab the CD-ROM exclusively, else fail", "grab it if you can", >> "don't grab it even if you could"? > > Perhaps IDE could be made to work cooperatively, but right now it > doesn't. But scsi-block should fail if it cannot manage the door > because it bypasses all the CD-ROM machinery and issues SCSI commands > directly. You've made a good case for why we really, really want managed_door on. With managed_door off, both software and humans basically run around confused. Why do we even offer managed_door off then? And isn't the automatic, *silent* fallback to the rotten user experience of managed_door off a recipe for support calls? [...]
