qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD d


From: Thomas Schmitt
Subject: Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Date: Sun, 06 Nov 2011 21:14:28 +0100

Hi,

i have finished CD and DVD tests with
  drive file=/dev/sg2,if=virtio -cdrom /dvdbuffer/pseudo_drive

There is substantial improvement towards if=scsi.

Actually everything works like a charm now. :))

It did not work for libburn out of the box, but i could work around
most of the obstacles.
Only remaining obstacle for normal usage: How to use the drive as
block device for reading ?
/dev/vda behaves like /dev/sg, not like /dev/sr.
  $ cat /dev/vda | wc
      0       0       0
(xorriso has no problem to read the media, because it does its
 entire drive i/o via libburn's MMC capabilities.)

I did not retry the USB drive. Will do tomorrow.
All SCSI commands, which get used with BD-R and BD-RE, should be
already tested now, nevertheless. BD-R are much like DVD+R, BD-RE
resemble DVD+RW.


Following is a preliminary summary of successes, an observation about
SSH reactivity, a proposal to curb file=/dev/sg*,if=scsi, and a report
about my workarounds to talk libburn into using /dev/vda.

-----------------------------------------------------------------------

Success with formerly successful use cases:

  All media types
  
    Tray loading and ejecting.

  CD-RW (and most probably CD-R)

    Writing a session with a single track with write type TAO.
    As first session and as add-on session.

  DVD+RW

    Writing to thoroughly formatted DVD+RW.

  DVD-RW (and most probably DVD-R)

    Writing with write type Incremental (aka Packet), multiple sessions.

    Blanking.

    Writing to thoroughly formatted DVD-RW.

  DVD+R

    Writing sessions without using RESERVE TRACK.

    Closing of medium.

-----------------------------------------------------------------------

Success with formerly failing or partially failing use cases:

  CD-RW (and most probably CD-R)

    Burning a CD SAO session
    Was: * DRIVE FREEZER, GUEST KILLER  
         Writing a first session to blank media with write type SAO.
         The guest freezes. The drive gets unusable by the host system
         until host reboot. Offending command:  SEND CUE SHEET

  DVD in general

    Telling the drive the desired DVD write speed with DVD+RW, DVD-RW
    (and most probably DVD-R), DVD+R
    Was: * DRIVE FREEZER, GUEST KILLER
         Guest freezes, qemu goes to 100% CPU, after SET STREAMING

    Media inquiry without blocking out any READ DISC STRUCTURE command.
    Was: * ANNOYING
         Guest SG_IO timeout with READ DISC STRUCTURE formats
         0x04 , 0x11 , 0x0e , 0x10.

  DVD+RW

    Writing to partly formatted DVD+RW and new unformatted DVD+RW.
    Was: SHOWSTOPPER
         Failure to write to unformatted or partly formatted DVD+RW.
         Offending command: FORMAT UNIT

  DVD-RW 

    Writing with write type DAO to blank sequential DVD-RW.
    Was: * GUEST KILLER
         Guest freezes with DVD-RW write type DAO. qemu is on 100 % CPU.
         Most probably after RESERVE TRACK, although this command is not shown
         by the SCSI log. But the command before it is shown and the medium
         has inconsistent knowledge of the desired track size.

    Formatting DVD-RW from sequential profile 0x14 to overwritable profile
    0x13.
    Was: * ANNOYING 
         Failure to format sequential DVD-RW, and to write to partially
         formatted DVD-RW.

    libburn shows progress with asynchronous BLANK and FORMAT UNIT.
    Was: * UGLY
         Failure to deliver progress of Blanking DVD-RW via REQUEST SENSE.

  DVD+R

    Writing a DVD+R session with RESERVE TRACK    
    Was: * GUEST KILLER MEDIUM KILLER
         Guest freezes, medium has unwritten open reserved track after
         RESERVE TRACK

-----------------------------------------------------------------------

Success with use cases not yet tried with if=scsi :

  CD-RW

    Blanking in mode fast.

    Closing CD-RW after writing a TAO session.

  DVD-RW (and most probably DVD-R)

    Closing DVD-RW after an Incremental session.

-------------------------------------------------------------------------

Observation:

  Now that everything works so well, i try multi-tasking.
  It appears that the SSH session is hampered for the time when
  longer SCSI transactions are waiting for the drive reply.
  E.g. when TEST UNIT READY needs 1600 milliseconds to tell that the
  drive is not ready.
  At the same time, the input line of another SSH session does not
  swiftly echo my toggling. It is not completely dead, but very slow.
  E.g. i get two single characters with two feelable delays and then
  all is normal again.
  I believe this is also the reason why i did not see the log message
  of the RESERVE track of the failed DAO run on if=scsi.

-------------------------------------------------------------------------

Proposal:

  As long as file=/dev/sg*,if=scsi is such a mine field, one should
  consider to disable it with CD-ish drives unless a special option
  is given at qemu start.

-----------------------------------------------------------------------
Obstacles and workarounds with if=virtio :

The device file /dev/vda does not support
  ioctl(fd, SG_GET_SCSI_ID, &sid);
or
  ioctl(fd, CDROM_DRIVE_STATUS, 0);
but rather on both returns -1 with errno 25
  ENOTTY   /* Not a typewriter */

Therefore libburn cannot confirm that this is indeed a CD drive.

I have to cheat libburn by a soft link /dev/sr1 and by a little hack
in the source code, before it is willing to send SCSI commands other
than TEST UNIT READY to this drive. (Will have to make libburn trust
the first byte from command INQUIRY which is 0x05 = "CD/DVD device"
according to SPC-3 table 83.)
I also made /dev/vda accessible for my normal user.

In /lib/udev/rules.d/50-udev-default.rules
  KERNEL=="vda",                                  SYMLINK+="sr1"
In /lib/udev/rules.d/91-permissions.rules
  KERNEL=="vda",                                  GROUP="cdrom"
(The developers of grep shall live long and prosper.) 

--------------------------------------------------------------------

Have a nice day :)

Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]