qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Markus Armbruster <armbru@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/3] scsi-disk: close drive on START_STOP
Date: Wed, 04 Dec 2013 22:59:42 +1100	[thread overview]
Message-ID: <529F192E.7080204@ozlabs.ru> (raw)
In-Reply-To: <87d2ldklji.fsf@blackfin.pond.sub.org>

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

  reply	other threads:[~2013-12-04 12:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-04  4:55 [Qemu-devel] [PATCH 0/3] scsi: eject fixed Alexey Kardashevskiy
2013-12-04  4:55 ` [Qemu-devel] [PATCH 1/3] scsi-disk: close drive on START_STOP Alexey Kardashevskiy
2013-12-04  8:58   ` Paolo Bonzini
2013-12-04  9:33     ` Markus Armbruster
2013-12-04 11:59       ` Alexey Kardashevskiy [this message]
2013-12-04 13:12         ` Markus Armbruster
2013-12-04 23:08           ` Alexey Kardashevskiy
2013-12-05  8:01             ` Markus Armbruster
2013-12-05 12:29       ` Markus Armbruster
2013-12-05 12:42         ` Alexey Kardashevskiy
2013-12-05 12:49           ` Paolo Bonzini
2013-12-06 11:18             ` Markus Armbruster
2013-12-04  4:55 ` [Qemu-devel] [PATCH 2/3] scsi-disk: check for meduim on ALLOW_MEDIUM_REMOVAL Alexey Kardashevskiy
2013-12-04  9:03   ` Paolo Bonzini
2013-12-04  9:35     ` Markus Armbruster
2013-12-04 12:03       ` Alexey Kardashevskiy
2013-12-04 12:51         ` Markus Armbruster
2013-12-04 17:34   ` Paolo Bonzini
2013-12-04  4:55 ` [Qemu-devel] [PATCH 3/3] scsi debug: print command name in debug Alexey Kardashevskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=529F192E.7080204@ozlabs.ru \
    --to=aik@ozlabs.ru \
    --cc=armbru@redhat.com \
    --cc=paulus@samba.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).