[Qemu-devel] Re: CD-ROM bug round-up

[Amit Shah]

On (Wed) 30 Mar 2011 [17:40:40], Stefan Hajnoczi wrote:
> Several of us have been investigating CD-ROM bugs.  Let's update each
> other, make sure we're not duplicating effort, and see if we can help
> each other make progress.
> 
> = Stefan =
> 
> Guests do not notice media change when using Linux host CD-ROM
> pass-through for two reasons:
> 1. QEMU is caching the device size for removable media and never updating it.
> 2. On Linux hosts the /dev/cdrom file descriptor needs to be reopened
> to refresh the underlying device size.
> 
> Patches have been posted to qemu-devel.
> 
> Libvirt does not recognize eject failure due to locked tray.  This
> causes libvirt to get out-of-sync and believe the medium was
> successfully changed.  A libvirt fix is in progress:
> https://bugzilla.redhat.com/show_bug.cgi?id=689101
> 
> = Anthony =
> 
> Using 'change' or scripted commands without a delay between closing
> the BlockDriverState and opening the new CD-ROM.  The 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.

It could be this, it could also be that our media_present/not-present
notifications aren't proper (more info below):

> = Amit =
> 
> Found that 2.6.38 and later guest kernels fail to report media change.

It's not 2.6.38 and later; it's somewhere around the time libata was
introduced and CDROM emulation went from ide to scsi in the kernel.
All current kernels (2.6.32 onwards) have this behaviour.

Also, this looks like it's due to multiple emulation bugs in QEMU:

- Command 46 (GET_CONFIGURATION) handles only specific cases.  The
  ones that aren't handled are the ones invoked by the guest kernel.

- Command 0 (TEST_UNIT_READY) replies with an error message if there's
  no medium instead of sending a reply with the no medium message.
  This causes the guest to do a soft-reset (invoking the HSM violation
  error message).

- Command 4a (GET_EVENT_STATUS_NOTIFICATION) is not implemented by us
  at all.

All these commands are marked as mandatory to be implemented by devices.

The commit Gleb pointed to in another message in this thread may have
something to do with media change not getting propogated as well:


    case GPCMD_TEST_UNIT_READY:
        if (bdrv_is_inserted(s->bs) && !s->cdrom_changed) {
            ide_atapi_cmd_ok(s);
        } else {
            s->cdrom_changed = 0;
            ide_atapi_cmd_error(s, SENSE_NOT_READY,
                                ASC_MEDIUM_NOT_PRESENT);
        }
        break;

Here, if cdrom got changed, we return an error message to the guest
instead of sending a UNIT_READY with UNIT_ATTENTION message.  So the
guest does its soft-reset thing, due to which the guest never then
notices the UNIT_ATTENTION pending message, causing the guest to think
it's still the same media in the device.

>  The new in-kernel media change polling framework issues ATAPI
> commands which are not implemented in hw/ide/core.c.

The in-kernel media change polling has nothing to do with our
emulation or the commands, btw.

> = Juan =
> 
> ATA HSM violation errors after live migration while CD-ROM read
> operations.  This is probably a hw/ide/* or DMA migration bug.

It could be a combination of the above and some migration state.

Overall, looks like we don't implement some mandatory commands from
the spec, causing the guest to try to bail out, and that makes the
guest lose some notifications.  The 'mount cd once, doesn't get
recognised, mount it again, it gets recognised' thing could be related
to this as well -- the bug Anthony talks about earlier.

For now, if we implement the above three commands properly, we would
already be a lot better.  We may then come across other commands that
might be needed to be implemented, but we can worry about that later.

                Amit