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: Paolo Bonzini
Subject: Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Date: Sat, 05 Nov 2011 16:53:17 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1

On 11/05/2011 03:37 PM, Thomas Schmitt wrote:
MMC-3 5.2 and MMC-5 6.2.3 state about processing of command BLANK with
Immed bit set to one:
"In response to the REQUEST SENSE command, unless an error has occurred,
  the Drive shall return a SK/ASC/ASCQ values set to
  NOT READY/LOGICAL UNIT NOT READY/OPERATION IN PROGRESS,
  with the sense key specific bytes set for progress indication."

But libburn gets on qemu

   TEST UNIT READY
   00 00 00 00 00 00
   +++ sense data = 71 00 02 00 00 00 00 0A 00 00 00 00 04 08 00 80 24 8B
   +++ key=2  asc=04h  ascq=08h   (     0 ms)

   REQUEST SENSE
   03 00 00 00 12 00
   From drive: 18b
   f0 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 00
        0 ms

It is ok that TEST UNIT READY reports the sense data with
   2 04 08 LOGICAL UNIT NOT READY, LONG WRITE IN PROGRESS
But it is not ok that REQUEST SENSE does not do the same.
On qemu it reports:
   0 00 00 NO ADDITIONAL SENSE INFORMATION

This is because QEMU always emulates REQUEST SENSE and always returns the sense data from the last request. Is this git master or 0.15? For git master, I would have expected REQUEST SENSE to return the correct sense data, but without updating it.

In general, it seems safer (and simpler?) if libburn uses TEST UNIT READY and its autosense data to report progress. REQUEST SENSE would be used if SG_IO reports CHECK CONDITION without SG_ERR_DRIVER_SENSE (but modern OSes will always emulate autosense even if the HBA does not support it) and possibly if TEST UNIT READY returns GOOD which is allowed by deprecated in MMC.

Paolo



reply via email to

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