Re: [Qemu-devel] [PATCH 0/5] scsi/atapi: MMC fixes

[Paolo Bonzini]

On 11/10/2011 07:17 PM, Thomas Schmitt wrote:
> Hi,
>
> > I only tested CD-RW DAO burning of an ISO image, plus invoking a bunch
> > of commands from Thomas's logs).  The burning succeeded but reading
> > the resulting medium failed consistently at 26 MB.  However, the same
> > happened even when doing CD passthrough via virtio, so it may be due to
> > a different bug.
>
> Did you get a sense code from the failure ?
>
> My best guess would be that you announced 26 MB by the SEND CUE SHEET
> command.
> Proposals for inspection of CD medium structure on real Linux:
>
>    wodim -v dev=/dev/sr0 -toc
>    cdrecord -v dev=/dev/sr0 -minfo
>    cdrskin -v dev=/dev/sr0 -minfo
>    xorriso -outdev /dev/sr0 -toc
>
> SCSI command logs are available by -V resp. -scsi_log on.

The READ TOC/PMA/ATIP at the end of burning gives (reformatted):

43 02 02 00 00 00 00 00 51 00
From drive: 81b
00 4f 01 01
01 14 00 a0 00 00 00 00 01 00 00
01 14 00 a1 00 00 00 00 01 00 00
01 14 00 a2 00 00 00 00 18 39 32 <<<
01 14 00 01 00 00 00 00 00 02 00
01 54 00 b0 ff ff ff 03 4f 3b 4a
01 54 00 c0 2c 00 ae 00 61 22 18
01 54 00 c1 cc 94 32 00 00 00 00

The data is BCD as far as I remember, so that the marked line would give 
~25% of the medium taken.  That's consistent with the ~200 MB image that 
I was burning.

I also noticed that after burning I sometimes need to eject it and 
reload the medium before its data becomes visible (no matter if from the 
host or the guest).  This is true even on the host.  Does this strike a 
bell?  I might be doing something wrong; perhaps I should be forcing 
cache=none together with scsi-block.

> Writing CD TAO or Packet, Incremental Streaming on DVD-R[W], or writing
> on DVD+R and BD-R without RESERVE TRACK, will cause the new readable
> size to be determined only after CLOSE TRACK SESSION.
> SEND CUE SHEET resp. RESERVE TRACK determine the size before writing
> begins.

Ok, so that would not work yet with scsi-block; it would return an LBA 
out of range error.  I don't have DVD+R media at hand, but I can try 
writing a patch for testing.

As a sidenote, passing a blank CD or unformatted DVD with scsi-block or 
virtio-blk-pci requires adding ",format=raw" to the -drive option.

> DVD-RAM and BD-RE can change their formatted size by FORMAT UNIT.
> In this case, the new size is determined as soon as TEST UNIT READY
> resp. REQUEST SENSE deliver no sense data any more.

On the other hand, they have no lead-in so they do not use negative LBA.

Formatting still has the problem of REQUEST SENSE returning bogus data, 
so it works but libburn might start the burning process while the disc 
is still being formatted.  Not surprisingly, the results are 
interesting.  I have a patch for that too.

> DVD+RW and formatted DVD-RW can grow their formatted size during
> writing. This is started by FORMAT UNIT but the size is decided only
> when writing ends. This end is not unambigously to detect. One may
> at any time continue writing as long as the medium is in the tray.

On the other hand, READ CAPACITY is updated as soon as formatting 
finishes (I think) and that's what matters for QEMU.  libburn sends READ 
CAPACITY and that's enough for QEMU to learn about the size of the disc.

> > The FORMAT UNIT command is still somewhat broken for block devices
> > because its parameter list length is not in the CDB. However it
> > works for CD/DVD drives, which mandate the length of the payload.
>
> Ouch. One will have to distinguish the interpretation by Peripheral
> Qualifier and Peripheral Device Type from INQUIRE (SSC = 0x02, MMC =
> 0x05).

Yes, that's what I did already.  Luckily the peripheral device type is 
already available in SCSIDevice.

Paolo