From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=56575 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Q4znW-0001sp-Li
	for qemu-devel@nongnu.org; Wed, 30 Mar 2011 14:07:23 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1Q4znU-0002Fv-2j
	for qemu-devel@nongnu.org; Wed, 30 Mar 2011 14:07:12 -0400
Received: from mail-yw0-f45.google.com ([209.85.213.45]:34030)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1Q4znT-0002Fr-V2
	for qemu-devel@nongnu.org; Wed, 30 Mar 2011 14:07:12 -0400
Received: by ywl41 with SMTP id 41so724042ywl.4
	for <qemu-devel@nongnu.org>; Wed, 30 Mar 2011 11:07:11 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <20110330165011.GF7766@redhat.com>
References: <AANLkTim_1kNJ6=13GpUXQBTbtjJUdAxL7=JXwCNq6W9G@mail.gmail.com>
	<20110330165011.GF7766@redhat.com>
Date: Wed, 30 Mar 2011 19:07:11 +0100
Message-ID: <AANLkTi=cVrNtCe_aMN-5Y_u1GyxtHP9b_vedODC79RBq@mail.gmail.com>
Subject: Re: [Qemu-devel] CD-ROM bug round-up
From: Stefan Hajnoczi <stefanha@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Gleb Natapov <gleb@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, Juan Quintela <quintela@redhat.com>, Markus Armbruster <armbru@redhat.com>, qemu-devel <qemu-devel@nongnu.org>, Ryan Harper <ryanh@us.ibm.com>, Amit Shah <amit.shah@redhat.com>

On Wed, Mar 30, 2011 at 5:50 PM, Gleb Natapov <gleb@redhat.com> wrote:
> On Wed, Mar 30, 2011 at 05:40:40PM +0100, Stefan Hajnoczi wrote:
>> =3D Anthony =3D
>>
>> Using 'change' or scripted commands without a delay between closing
>> the BlockDriverState and opening the new CD-ROM. =A0The guest does not
>> have a chance to poll the drive and determine a medium present ->
>> medium not present transition followed by a medium not present ->
>> medium present transition.
>>
>> A fix for this does not exist yet and might be tricky since we need to
>> delay or wait for the guest to poll once before opening the new
>> CD-ROM.
>>
> This sounds familiar and should have been fixed by commit
> 93c8cfd9e67a62711b86f4c93747566885eb7928

Excellent, thanks for pointing this out.  We need to figure out
whether this mechanism is insufficient for some guests.

On a Windows-related note, I've found that Windows 2003 Server sends
START STOP UNIT to eject the medium without unlocking the tray first.
When the CD-ROM is passed through to a Linux host CD-ROM drive the
eject ioctl fails if the tray is locked.  I haven't investigated this
more yet.

Stefan