| Message ID | 1386132925-16728-2-git-send-email-aik@ozlabs.ru |
|---|---|
| State | New |
| Headers | show |
Il 04/12/2013 05:55, Alexey Kardashevskiy ha scritto: > Normally the user is expected to eject DVD if it is not locked by > the guest. eject_device() makes few checks and calls bdrv_close() > if DVD is not in use. > > However it is still possible to eject DVD even if it is in use. > For that, QEMU sets "eject requested" flag, the guest reads it, issues > ALLOW_MEDIUM_REMOVAL(enable=1) and START_STOP(start=0). But in this case, > bdrv_close() is not called anywhere so it remains "inserted" in QEMU's > terms. This is expected behavior, and matches what IDE does. Markus, can you confirm? Paolo
Paolo Bonzini <pbonzini@redhat.com> writes: > Il 04/12/2013 05:55, Alexey Kardashevskiy ha scritto: >> Normally the user is expected to eject DVD if it is not locked by >> the guest. eject_device() makes few checks and calls bdrv_close() >> if DVD is not in use. >> >> However it is still possible to eject DVD even if it is in use. >> For that, QEMU sets "eject requested" flag, the guest reads it, issues >> ALLOW_MEDIUM_REMOVAL(enable=1) and START_STOP(start=0). But in this case, >> bdrv_close() is not called anywhere so it remains "inserted" in QEMU's >> terms. > > This is expected behavior, and matches what IDE does. > > Markus, can you confirm? Confirmed. See commit 4be9762. Alexey, monitor commands eject does two things: it first opens the tray, and if that works, it removes the medium. If the tray is locked closed, it tells the device model that eject was requested. Works just like the physical eject button. With -f, it then rips out the medium. This is similar to opening the tray with a unbent paperclip. Let's ignore this case. The scsi-cd device model tells the guest about the eject request. A well-behaved guest will then command the device to unlock and open the tray. The guest uses the same commands on behalf of its applications, e.g. /usr/bin/eject. Your patch changes behavior of "eject /dev/sr0 && eject -t /dev/sr0": you no longer get the same medium back. You normally do with real hardware. The somewhat unfortunate consequence is that monitor command eject can only remove the medium when the tray is not locked.
On 12/04/2013 08:33 PM, Markus Armbruster wrote: > Paolo Bonzini <pbonzini@redhat.com> writes: > >> Il 04/12/2013 05:55, Alexey Kardashevskiy ha scritto: >>> Normally the user is expected to eject DVD if it is not locked by >>> the guest. eject_device() makes few checks and calls bdrv_close() >>> if DVD is not in use. >>> >>> However it is still possible to eject DVD even if it is in use. >>> For that, QEMU sets "eject requested" flag, the guest reads it, issues >>> ALLOW_MEDIUM_REMOVAL(enable=1) and START_STOP(start=0). But in this case, >>> bdrv_close() is not called anywhere so it remains "inserted" in QEMU's >>> terms. >> >> This is expected behavior, and matches what IDE does. >> >> Markus, can you confirm? > > Confirmed. See commit 4be9762. > > Alexey, monitor commands eject does two things: it first opens the tray, > and if that works, it removes the medium. > > If the tray is locked closed, it tells the device model that eject was > requested. Works just like the physical eject button. > > With -f, it then rips out the medium. This is similar to opening the > tray with a unbent paperclip. Let's ignore this case. > > The scsi-cd device model tells the guest about the eject request. A > well-behaved guest will then command the device to unlock and open the > tray. > > The guest uses the same commands on behalf of its applications, > e.g. /usr/bin/eject. > > Your patch changes behavior of "eject /dev/sr0 && eject -t /dev/sr0": > you no longer get the same medium back. You normally do with real > hardware. > > The somewhat unfortunate consequence is that monitor command eject can > only remove the medium when the tray is not locked. Oh. Wow. Nice :-/ Ok. So. It is expected that the real system will close the tray back if it was mounted, is not it? Right now, after "eject" "info block" is like this: cd1: virtimg/Fedora-19-ppc64-netinst.iso (raw) Removable device: locked, tray open And the mountpoint does not work in the guest. The state above even persists after "umount" in the guest. It only becomes correct again (tray==closed) when I mount DVD again. Is it all expected to work like this? Thanks.
Alexey Kardashevskiy <aik@ozlabs.ru> writes: > On 12/04/2013 08:33 PM, Markus Armbruster wrote: >> Paolo Bonzini <pbonzini@redhat.com> writes: >> >>> Il 04/12/2013 05:55, Alexey Kardashevskiy ha scritto: >>>> Normally the user is expected to eject DVD if it is not locked by >>>> the guest. eject_device() makes few checks and calls bdrv_close() >>>> if DVD is not in use. >>>> >>>> However it is still possible to eject DVD even if it is in use. >>>> For that, QEMU sets "eject requested" flag, the guest reads it, issues >>>> ALLOW_MEDIUM_REMOVAL(enable=1) and START_STOP(start=0). But in this case, >>>> bdrv_close() is not called anywhere so it remains "inserted" in QEMU's >>>> terms. >>> >>> This is expected behavior, and matches what IDE does. >>> >>> Markus, can you confirm? >> >> Confirmed. See commit 4be9762. >> >> Alexey, monitor commands eject does two things: it first opens the tray, >> and if that works, it removes the medium. >> >> If the tray is locked closed, it tells the device model that eject was >> requested. Works just like the physical eject button. >> >> With -f, it then rips out the medium. This is similar to opening the >> tray with a unbent paperclip. Let's ignore this case. >> >> The scsi-cd device model tells the guest about the eject request. A >> well-behaved guest will then command the device to unlock and open the >> tray. >> >> The guest uses the same commands on behalf of its applications, >> e.g. /usr/bin/eject. >> >> Your patch changes behavior of "eject /dev/sr0 && eject -t /dev/sr0": >> you no longer get the same medium back. You normally do with real >> hardware. >> >> The somewhat unfortunate consequence is that monitor command eject can >> only remove the medium when the tray is not locked. > > > Oh. Wow. Nice :-/ > > Ok. So. It is expected that the real system will close the tray back if it > was mounted, is not it? > > Right now, after "eject" "info block" is like this: > > cd1: virtimg/Fedora-19-ppc64-netinst.iso (raw) > Removable device: locked, tray open > > And the mountpoint does not work in the guest. The state above even > persists after "umount" in the guest. It only becomes correct again > (tray==closed) when I mount DVD again. > > Is it all expected to work like this? Thanks. Can't reproduce, but can reproduce something similar. Freshly booted guest running RHEL-7 alpha, with the CD mounted: (qemu) info block cd cd: r7.iso (raw, read-only) Removable device: locked, tray closed Looks good. Try to eject: (qemu) eject cd Device 'cd' is locked Looks good. This should have signalled the guest "user wants to eject". The guest should either ignore it, or unmount, unlock and eject. Apparently, it does that: (qemu) info block cd cd: r7.iso (raw, read-only) Removable device: locked, tray closed (qemu) eject cd Device 'cd' is locked (qemu) info block cd cd: r7.iso (raw, read-only) Removable device: locked, tray closed (qemu) info block cd cd: r7.iso (raw, read-only) Removable device: not locked, tray open Except it forgets to unmount! dmesg has "VFS: busy inodes on changed media or resized disk sr0". Need somebody to find out how exactly this fails, and whether it's a guest bug or a QEMU bug.
On 12/05/2013 12:12 AM, Markus Armbruster wrote: > Alexey Kardashevskiy <aik@ozlabs.ru> writes: > >> On 12/04/2013 08:33 PM, Markus Armbruster wrote: >>> Paolo Bonzini <pbonzini@redhat.com> writes: >>> >>>> Il 04/12/2013 05:55, Alexey Kardashevskiy ha scritto: >>>>> Normally the user is expected to eject DVD if it is not locked by >>>>> the guest. eject_device() makes few checks and calls bdrv_close() >>>>> if DVD is not in use. >>>>> >>>>> However it is still possible to eject DVD even if it is in use. >>>>> For that, QEMU sets "eject requested" flag, the guest reads it, issues >>>>> ALLOW_MEDIUM_REMOVAL(enable=1) and START_STOP(start=0). But in this case, >>>>> bdrv_close() is not called anywhere so it remains "inserted" in QEMU's >>>>> terms. >>>> >>>> This is expected behavior, and matches what IDE does. >>>> >>>> Markus, can you confirm? >>> >>> Confirmed. See commit 4be9762. >>> >>> Alexey, monitor commands eject does two things: it first opens the tray, >>> and if that works, it removes the medium. >>> >>> If the tray is locked closed, it tells the device model that eject was >>> requested. Works just like the physical eject button. >>> >>> With -f, it then rips out the medium. This is similar to opening the >>> tray with a unbent paperclip. Let's ignore this case. >>> >>> The scsi-cd device model tells the guest about the eject request. A >>> well-behaved guest will then command the device to unlock and open the >>> tray. >>> >>> The guest uses the same commands on behalf of its applications, >>> e.g. /usr/bin/eject. >>> >>> Your patch changes behavior of "eject /dev/sr0 && eject -t /dev/sr0": >>> you no longer get the same medium back. You normally do with real >>> hardware. >>> >>> The somewhat unfortunate consequence is that monitor command eject can >>> only remove the medium when the tray is not locked. >> >> >> Oh. Wow. Nice :-/ >> >> Ok. So. It is expected that the real system will close the tray back if it >> was mounted, is not it? >> >> Right now, after "eject" "info block" is like this: >> >> cd1: virtimg/Fedora-19-ppc64-netinst.iso (raw) >> Removable device: locked, tray open >> >> And the mountpoint does not work in the guest. The state above even >> persists after "umount" in the guest. It only becomes correct again >> (tray==closed) when I mount DVD again. >> >> Is it all expected to work like this? Thanks. > > Can't reproduce, but can reproduce something similar. Freshly booted > guest running RHEL-7 alpha, with the CD mounted: > > (qemu) info block cd > > cd: r7.iso (raw, read-only) > Removable device: locked, tray closed > > Looks good. Try to eject: > > (qemu) eject cd > Device 'cd' is locked > > Looks good. This should have signalled the guest "user wants to eject". > The guest should either ignore it, or unmount, unlock and eject. > Apparently, it does that: > > (qemu) info block cd > > cd: r7.iso (raw, read-only) > Removable device: locked, tray closed > (qemu) eject cd > Device 'cd' is locked > (qemu) info block cd > > cd: r7.iso (raw, read-only) > Removable device: locked, tray closed > (qemu) info block cd > > cd: r7.iso (raw, read-only) > Removable device: not locked, tray open > > Except it forgets to unmount! dmesg has "VFS: busy inodes on changed > media or resized disk sr0". > > Need somebody to find out how exactly this fails, and whether it's a > guest bug or a QEMU bug. The guest unlocks DVD (by sending ALLOW PERMIT MEDIUM REMOVAL) and stops DVD (by sending START_STOP). Is there any other message missing which would do real physical eject? What does it have to do with unmount (which is purely the guest software state)?
Alexey Kardashevskiy <aik@ozlabs.ru> writes: > On 12/05/2013 12:12 AM, Markus Armbruster wrote: >> Alexey Kardashevskiy <aik@ozlabs.ru> writes: >> >>> On 12/04/2013 08:33 PM, Markus Armbruster wrote: >>>> Paolo Bonzini <pbonzini@redhat.com> writes: >>>> >>>>> Il 04/12/2013 05:55, Alexey Kardashevskiy ha scritto: >>>>>> Normally the user is expected to eject DVD if it is not locked by >>>>>> the guest. eject_device() makes few checks and calls bdrv_close() >>>>>> if DVD is not in use. >>>>>> >>>>>> However it is still possible to eject DVD even if it is in use. >>>>>> For that, QEMU sets "eject requested" flag, the guest reads it, issues >>>>>> ALLOW_MEDIUM_REMOVAL(enable=1) and START_STOP(start=0). But in this case, >>>>>> bdrv_close() is not called anywhere so it remains "inserted" in QEMU's >>>>>> terms. >>>>> >>>>> This is expected behavior, and matches what IDE does. >>>>> >>>>> Markus, can you confirm? >>>> >>>> Confirmed. See commit 4be9762. >>>> >>>> Alexey, monitor commands eject does two things: it first opens the tray, >>>> and if that works, it removes the medium. >>>> >>>> If the tray is locked closed, it tells the device model that eject was >>>> requested. Works just like the physical eject button. >>>> >>>> With -f, it then rips out the medium. This is similar to opening the >>>> tray with a unbent paperclip. Let's ignore this case. >>>> >>>> The scsi-cd device model tells the guest about the eject request. A >>>> well-behaved guest will then command the device to unlock and open the >>>> tray. >>>> >>>> The guest uses the same commands on behalf of its applications, >>>> e.g. /usr/bin/eject. >>>> >>>> Your patch changes behavior of "eject /dev/sr0 && eject -t /dev/sr0": >>>> you no longer get the same medium back. You normally do with real >>>> hardware. >>>> >>>> The somewhat unfortunate consequence is that monitor command eject can >>>> only remove the medium when the tray is not locked. >>> >>> >>> Oh. Wow. Nice :-/ >>> >>> Ok. So. It is expected that the real system will close the tray back if it >>> was mounted, is not it? >>> >>> Right now, after "eject" "info block" is like this: >>> >>> cd1: virtimg/Fedora-19-ppc64-netinst.iso (raw) >>> Removable device: locked, tray open >>> >>> And the mountpoint does not work in the guest. The state above even >>> persists after "umount" in the guest. It only becomes correct again >>> (tray==closed) when I mount DVD again. >>> >>> Is it all expected to work like this? Thanks. >> >> Can't reproduce, but can reproduce something similar. Freshly booted >> guest running RHEL-7 alpha, with the CD mounted: >> >> (qemu) info block cd >> >> cd: r7.iso (raw, read-only) >> Removable device: locked, tray closed >> >> Looks good. Try to eject: >> >> (qemu) eject cd >> Device 'cd' is locked >> >> Looks good. This should have signalled the guest "user wants to eject". >> The guest should either ignore it, or unmount, unlock and eject. >> Apparently, it does that: >> >> (qemu) info block cd >> >> cd: r7.iso (raw, read-only) >> Removable device: locked, tray closed >> (qemu) eject cd >> Device 'cd' is locked >> (qemu) info block cd >> >> cd: r7.iso (raw, read-only) >> Removable device: locked, tray closed >> (qemu) info block cd >> >> cd: r7.iso (raw, read-only) >> Removable device: not locked, tray open >> >> Except it forgets to unmount! dmesg has "VFS: busy inodes on changed >> media or resized disk sr0". >> >> Need somebody to find out how exactly this fails, and whether it's a >> guest bug or a QEMU bug. > > > The guest unlocks DVD (by sending ALLOW PERMIT MEDIUM REMOVAL) and stops > DVD (by sending START_STOP). Is there any other message missing which would > do real physical eject? START_STOP has a "load/eject" flag that causes load with start and eject with stop. > What does it have to do with unmount (which is purely the guest software > state)? Not sure I understand you here. A guest that voluntarily ejects a medium while keeping it mounted gets what it asked for: breakage.
Markus Armbruster <armbru@redhat.com> writes: > Paolo Bonzini <pbonzini@redhat.com> writes: > >> Il 04/12/2013 05:55, Alexey Kardashevskiy ha scritto: >>> Normally the user is expected to eject DVD if it is not locked by >>> the guest. eject_device() makes few checks and calls bdrv_close() >>> if DVD is not in use. >>> >>> However it is still possible to eject DVD even if it is in use. >>> For that, QEMU sets "eject requested" flag, the guest reads it, issues >>> ALLOW_MEDIUM_REMOVAL(enable=1) and START_STOP(start=0). But in this case, >>> bdrv_close() is not called anywhere so it remains "inserted" in QEMU's >>> terms. >> >> This is expected behavior, and matches what IDE does. >> >> Markus, can you confirm? > > Confirmed. See commit 4be9762. > > Alexey, monitor commands eject does two things: it first opens the tray, > and if that works, it removes the medium. > > If the tray is locked closed, it tells the device model that eject was > requested. Works just like the physical eject button. > > With -f, it then rips out the medium. This is similar to opening the > tray with a unbent paperclip. Let's ignore this case. > > The scsi-cd device model tells the guest about the eject request. A > well-behaved guest will then command the device to unlock and open the > tray. > > The guest uses the same commands on behalf of its applications, > e.g. /usr/bin/eject. > > Your patch changes behavior of "eject /dev/sr0 && eject -t /dev/sr0": > you no longer get the same medium back. You normally do with real > hardware. Alexey asked me for details on IRC. $ qemu -nodefaults -monitor stdio -S -machine accel=kvm -m 512 -display vnc=:0 -device cirrus-vga -drive if=none,id=disk,file=test.qcow2 -device ide-hd,drive=disk,bus=ide.0 -drive if=none,id=cd,file=f16.iso -device ide-cd,drive=cd,bus=ide.1 QEMU 1.7.50 monitor - type 'help' for more information (qemu) info block cd cd: f16.iso (raw) Removable device: not locked, tray closed Boot the guest (Fedora 16, no X) (qemu) c The guest locked the tray: (qemu) info block cd cd: f16.iso (raw) Removable device: locked, tray closed In the guest, log in as root on the console, and run # eject /dev/sr0 Makes the guest open the tray: (qemu) info block cd cd: f16.iso (raw) Removable device: locked, tray open In the guest, run # eject -t /dev/sr0 Makes the guest close the tray: (qemu) info block cd cd: f16.iso (raw) Removable device: locked, tray closed Verify the guest can access the medium: # mount -r /dev/sr0 /mnt > The somewhat unfortunate consequence is that monitor command eject can > only remove the medium when the tray is not locked.
On 12/05/2013 11:29 PM, Markus Armbruster wrote: > Markus Armbruster <armbru@redhat.com> writes: > >> Paolo Bonzini <pbonzini@redhat.com> writes: >> >>> Il 04/12/2013 05:55, Alexey Kardashevskiy ha scritto: >>>> Normally the user is expected to eject DVD if it is not locked by >>>> the guest. eject_device() makes few checks and calls bdrv_close() >>>> if DVD is not in use. >>>> >>>> However it is still possible to eject DVD even if it is in use. >>>> For that, QEMU sets "eject requested" flag, the guest reads it, issues >>>> ALLOW_MEDIUM_REMOVAL(enable=1) and START_STOP(start=0). But in this case, >>>> bdrv_close() is not called anywhere so it remains "inserted" in QEMU's >>>> terms. >>> >>> This is expected behavior, and matches what IDE does. >>> >>> Markus, can you confirm? >> >> Confirmed. See commit 4be9762. >> >> Alexey, monitor commands eject does two things: it first opens the tray, >> and if that works, it removes the medium. >> >> If the tray is locked closed, it tells the device model that eject was >> requested. Works just like the physical eject button. >> >> With -f, it then rips out the medium. This is similar to opening the >> tray with a unbent paperclip. Let's ignore this case. >> >> The scsi-cd device model tells the guest about the eject request. A >> well-behaved guest will then command the device to unlock and open the >> tray. >> >> The guest uses the same commands on behalf of its applications, >> e.g. /usr/bin/eject. >> >> Your patch changes behavior of "eject /dev/sr0 && eject -t /dev/sr0": >> you no longer get the same medium back. You normally do with real >> hardware. > > Alexey asked me for details on IRC. > > $ qemu -nodefaults -monitor stdio -S -machine accel=kvm -m 512 -display vnc=:0 -device cirrus-vga -drive if=none,id=disk,file=test.qcow2 -device ide-hd,drive=disk,bus=ide.0 -drive if=none,id=cd,file=f16.iso -device ide-cd,drive=cd,bus=ide.1 > QEMU 1.7.50 monitor - type 'help' for more information > (qemu) info block cd > > cd: f16.iso (raw) > Removable device: not locked, tray closed > > Boot the guest (Fedora 16, no X) > > (qemu) c > > The guest locked the tray: > > (qemu) info block cd > > cd: f16.iso (raw) > Removable device: locked, tray closed > > In the guest, log in as root on the console, and run > > # eject /dev/sr0 > > Makes the guest open the tray: > > (qemu) info block cd > > cd: f16.iso (raw) > Removable device: locked, tray open > > In the guest, run > > # eject -t /dev/sr0 > > Makes the guest close the tray: > > (qemu) info block cd > > cd: f16.iso (raw) > Removable device: locked, tray closed > > Verify the guest can access the medium: > > # mount -r /dev/sr0 /mnt > >> The somewhat unfortunate consequence is that monitor command eject can >> only remove the medium when the tray is not locked. Thanks! Just out of curiosity. A lot (in fact, all around me) dvd drives do not support trayclose as they are in laptops or servers (which use the same laptop models). I cannot even verify how this "eject -t" exactly works - no hardware around me. And even if I could find it, I could easily take the disc off the tray in that short period of time between tray is open and tray is closed but we still absolutely want "eject" + "eject -t" to work as you described. Why exactly? :) Only because change of behavior is bad? Just asking. Thanks.
Il 05/12/2013 13:42, Alexey Kardashevskiy ha scritto: > Thanks! > > Just out of curiosity. A lot (in fact, all around me) dvd drives do not > support trayclose as they are in laptops or servers (which use the same > laptop models). I cannot even verify how this "eject -t" exactly works - no > hardware around me. And even if I could find it, I could easily take the > disc off the tray in that short period of time between tray is open and > tray is closed but we still absolutely want "eject" + "eject -t" to work as > you described. Taking the disc off the tray is equivalent to going to the monitor and doing "eject -f cd". I.e. programmatic actions leave the disc in (at least if you do not consider laptops and servers; but the guest can detect whether the tray can be auto-closed, and we tell it that it can). Out-of-band user actions force the disc out. > Why exactly? :) Only because change of behavior is bad? Just asking. Thanks. The only practical use of CDs is installation, and it took a looooong time to get it to work with all sorts of guests. Paolo
Paolo Bonzini <pbonzini@redhat.com> writes: > Il 05/12/2013 13:42, Alexey Kardashevskiy ha scritto: >> Thanks! >> >> Just out of curiosity. A lot (in fact, all around me) dvd drives do not >> support trayclose as they are in laptops or servers (which use the same >> laptop models). I cannot even verify how this "eject -t" exactly works - no >> hardware around me. And even if I could find it, I could easily take the >> disc off the tray in that short period of time between tray is open and >> tray is closed but we still absolutely want "eject" + "eject -t" to work as >> you described. > > Taking the disc off the tray is equivalent to going to the monitor and > doing "eject -f cd". Actually, monitor command "eject -f" is like poking the little button hidden in that little hole with an unbent paperclip or something, which makes the drive eject whether the OS likes it or not (and tends to make the OS rather upset), then removing the medium. Monitor command "eject" without -f is like pushing the "normal" button, and if that ejects, and the medium wasn't locked, removing the medium. Yes, that's not exactly elegant semantics. /usr/bin/eject is something else entirely: it sends commands to the device. Such commands can make the drive eject and load, but they cannot cause the medium removal without further user action. Exactly the same on real and virtual systems. > I.e. programmatic actions leave the disc in (at least if you do not > consider laptops and servers; but the guest can detect whether the tray > can be auto-closed, and we tell it that it can). Out-of-band user > actions force the disc out. > >> Why exactly? :) Only because change of behavior is bad? Just asking. Thanks. > > The only practical use of CDs is installation, and it took a looooong > time to get it to work with all sorts of guests. Indeed.
diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c index 74e6a14..08b6135 100644 --- a/hw/scsi/scsi-disk.c +++ b/hw/scsi/scsi-disk.c @@ -1283,6 +1283,9 @@ static int scsi_disk_emulate_start_stop(SCSIDiskReq *r) if (s->tray_open != !start) { bdrv_eject(s->qdev.conf.bs, !start); s->tray_open = !start; + if (!start) { + bdrv_close(s->qdev.conf.bs); + } } } return 0;
Normally the user is expected to eject DVD if it is not locked by the guest. eject_device() makes few checks and calls bdrv_close() if DVD is not in use. However it is still possible to eject DVD even if it is in use. For that, QEMU sets "eject requested" flag, the guest reads it, issues ALLOW_MEDIUM_REMOVAL(enable=1) and START_STOP(start=0). But in this case, bdrv_close() is not called anywhere so it remains "inserted" in QEMU's terms. This adds a block device removal on the SCSI device stop. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> --- hw/scsi/scsi-disk.c | 3 +++ 1 file changed, 3 insertions(+)