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

[Thomas Schmitt]

Hi,

> 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

I was not aware you did your tests with libburn. :)
(Regrettably the web site with the wiki is down. Should be up again soon.)


> 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.

MSF. Minutes, Seconds, Frames. (M<90): LBA = (M * 60 + S) * 75 + F - 150;
Caused by format code 0010b = RAW TOC. MMC transmits it binary in single
bytes although the media may have it as BCD.
I compute 103325 blocks = 206 MB. So this looks correct.

What were the exact symptoms of the read failure ?


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

> 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.

At least Linux is not aware of what i am doing via libburn.
This is not only about size but also about cached content.

Andy Polyakov has addressed this in growisofs by either ejecting and
reloading the tray, or by ioctl(BLKFLSBUF). From growisofs.c:
 * - Linux: deploy BLKFLSBUF to avoid media reloads when possible;
Implementation is in dvd+rw-tools-7.1/transport.hxx:
    int is_reload_needed (int same_capacity)
    {   if (same_capacity && ioctl (fd,0x1261,0) == 0) // try BLKFLSBUF
            return 0;
        else
            return ioctl (fd,CDROM_MEDIA_CHANGED,CDSL_CURRENT) == 0;
    }
If i understand this right, then it avoids tray snapping only if size
is not changed, or if the kernel learned about the change by itself.

I oppose the automatic physical tray movement because this might cause
accidents with human or silicone injuries.
BLKFLSBUF did not help for me, when i tried it on SuSE 10.
Maybe i should examine it again on Debian 6.

So for now i advise users to eject the medium after xorriso is done
with it. xorriso resp. libburn itself has no problem with the kernel
ignorance. (It has no problem with reading the end of CD TAO tracks
either.)


> Ok, so that would not work yet with scsi-block; it would return an LBA out
> of range error.

udev on a Debian 6 with Gnome desktop running gets quite reliably the
kernel events from opening and closing file descriptors to the device
node. (With only the graphical login running, there are fewer events.)

But with qemu, the drive is opened from start to end of the virtual
machine life. And the quest system probably does not tell the drive
about a close(2) event. So qemu will not learn from the guest and
cannot go through a close(2)-open(2) cycle on the host.

qemu should try its best to get any change that was noticed by the host
system, e.g. after manual reloading of the drive.
(Maybe by ioctl(CDROM_MEDIA_CHANGED) as growisofs does ?)

Some opportunity to close(2)-and-open(2) the host drive by command
of the qemu user could be helpful.


> I don't have DVD+R media at hand, but I can try writing a
> patch for testing.

CD-RW TAO should have the same effect.
You get TAO from xorriso when writing a second session to appendable CD
(i.e. first session without -close on), or you can get it by hiding
the input size from its cdrecord emulation:
  cat my_track_source_file | \
  xorriso -as cdrecord blank=fast -v -V dev=/dev/sr0 -

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

A test about host and guest awareness:

On the guest, i burned and checkread a CD-RW SAO session with closing
  $ xorriso -md5 on -outdev /dev/sr1 -close on -add /usr/include --
  $ xorriso -md5 on -indev /dev/sr1 -check_md5_r sorry / --

xorriso says that all is well. It sees 3710 blocks of ISO 9660 filesystem.

dd on host and guest read 0 bytes without error message.

I eject and reload on the host
  $ eject /dev/sr2
  $ eject -t /dev/sr2

The host still reads 0 bytes. The guest too.

I shutdown the guest and qemu.

The host knows immediately that there are 
  3860+0 records in
which matches the session size of 3710 blocks plus 150 blocks of padding.

So it is the close(2) call of qemu which makes the host kernel aware.
(But this is not so with all Linux kernels of the last years.)

I restarted qemu and the guest. Burned a new, larger session to CD-RW.
Host and guest still deliver the old size of 3860 blocks.
Nothing i do can change the hosts idea of size, until i shutdown qemu.
(Tried eject, wodim, cdrskin, ...)

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

qemu device setup was this new variation:

> 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.

I test

  -drive file=/dev/sr2,if=none,id=scsicd,format=raw \
  -device 
virtio-blk-pci,drive=scsicd,logical_block_size=2048,physical_block_size=2048 \
  -cdrom /dvdbuffer/pseudo_drive

Yep. qemu starts with a blank CD-RW.

With empty tray it still refuses with

  qemu-system-x86_64: -device 
virtio-blk-pci,drive=scsicd,logical_block_size=2048,physical_block_size=2048: 
Device needs media, but drive is empty


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

Have a nice day :)

Thomas