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

[Thomas Schmitt]

Hi

i can prevent the EPERM failures of ioctl(SG_IO) by opening the
device file /dev/sg1 with O_RDWR rather than O_RDONLY.

In block/raw-posix.c:raw_open_common i implemented this hack:

      printf("block/raw-posix.c: raw_open_common(\"%s\", %x)\n",
             filename, s->open_flags);
      if (strncmp(filename, "/dev/sg", 7) == 0) {
          s->open_flags |= O_RDWR;
          printf("block/raw-posix.c: /dev/sg hack: s->open_flags is now %x\n",
                 s->open_flags);
      }

before
      s->fd = -1;
      fd = qemu_open(filename, s->open_flags, 0644);

This enables CD-RW burning.
Burning of DVD+RW still fails quite badly, though.

Paolo:
May i ask for the favor that you try to add O_RDWR to the qemu_open()
call of passthrough devices ?

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

While booting the guest, i get these messages

  block/raw-posix.c: raw_open_common("/dvdbuffer/i386-install.qemu", 1000)
  block/raw-posix.c: raw_open_common("/dvdbuffer/i386-install.qemu", 1002)
  block/raw-posix.c: raw_open_common("/dev/sg1", 1000)
  block/raw-posix.c: /dev/sg hack: s->open_flags is now 1002
  block/raw-posix.c: raw_open_common("/dev/sg1", 1000)
  block/raw-posix.c: /dev/sg hack: s->open_flags is now 1002
  block/raw-posix.c: raw_open_common("/dvdbuffer/pseudo_drive", 1000)
  block/raw-posix.c: raw_open_common("/dvdbuffer/pseudo_drive", 1000)

The printf for failed ioctl is still present, but does not report
anymore: 
  posix-aio-compat.c: handle_aiocb_ioctl: ioctl(12, 0x2285, ), ret= -1 , errno= 
1

I dare to burn a DVD+RW
  xorriso -for_backup -scsi_log on -dev /dev/sr0 -add /usr/include --

It blocks on
  SET STREAMING
  b6 00 00 00 00 00 00 00 00 00 1c 00 
  To drive: 28b
  00 00 00 00 00 00 00 00 00 23 04 88 10 00 00 00 00 00 03 e8
  10 00 00 00 00 00 03 e8 

The guest system finally gets incommunicado, while the qemu process
on the host consumes 100 % CPU.
No further messages appear on the qemu start terminal.
After 10 minutes i issued on the host "kill -9" to get rid of the qemu
process.

I can start it again, but it does not accept SSH connections but rather
lets the CPU glow at 100 %. It can be killed again.
I reboot the host.
Now qemu can boot the guest again.


I retry with with CD-RW (and thus no SET STREAMING)

It burns !
Afterwards i have one more session on the CD-RW.

  Drive current: -dev '/dev/sr1'
  Drive type   : vendor 'TSSTcorp' product 'CDDVDW SH-S223B' revision 'SB02'
  Media current: CD-RW
  Media product: 97m15s35f/79m59s74f , Nan-Ya Plastics Corporation
  Media status : is written , is appendable
  Media blocks : 43153 readable , 309794 writable , 359847 overall
  TOC layout   : Idx ,  sbsector ,       Size , Volume Id
  ISO session  :   1 ,         0 ,     27633s , ISOIMAGE
  ISO session  :   2 ,     39183 ,      3818s , ISOIMAGE
  Media summary: 2 sessions, 31753 data blocks, 62.0m data,  605m free
  Media nwa    : 50053s

I do a checkread with the MD5s of the single content files, which
were generated and recorded by xorriso option -for_backup:

  $ xorriso -for_backup -dev /dev/sr1 -check_md5_r sorry / --
  ...
  Media summary: 2 sessions, 31753 data blocks, 62.0m data,  605m free
  Volume id    : 'ISOIMAGE'
  xorriso : UPDATE : 65536 content bytes read in 6 seconds
  xorriso : UPDATE :  13931k content bytes read in 11 seconds
  xorriso : UPDATE :  30202k content bytes read in 16 seconds
  xorriso : UPDATE :  45284k content bytes read in 21 seconds
  xorriso : UPDATE :  61991k content bytes read in 26 seconds
  xorriso : UPDATE :  64692k content bytes read in 27 seconds
  File contents and their MD5 checksums match.

Comparing ISO image content with hard disk content:

  $ xorriso -dev /dev/sr1 -compare_r /usr/include /usr/include
  ...
  xorriso : UPDATE : 6015501 content bytes read in 9 seconds
  Both file objects match as far as expectable.
  $

Whew !

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

Ok. But why does it fail with SET STREAMING ?
This will demand a completely new dive into the entrails of qemu.
Maybe not before tomorrow.

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

Above hack does not repair the timeouts with READ DISC STRUCTURE,
which i use to inquire DVD media.
The problematic commands are accompanied by this ioctl failure:
  posix-aio-compat.c: handle_aiocb_ioctl: ioctl(12, 0x2285, ),
                                          ret= -1 , errno= 22
This is EINVAL /* Invalid argument */.
The debugging message appears as soon the SCSI command is attempted,
not waiting until the timeout finally snaps.

I verified once again on the host system, that the commands succeed.
They deliver large results:
  READ DISC STRUCTURE
  ad 00 00 00 00 00 00 04 08 04 00 00 
  From drive: 2052b
  ...
  READ DISC STRUCTURE
  ad 00 00 00 00 00 00 11 01 04 00 00 
  From drive: 260b
  ...

But the mere size cannot be the reason, because on the guest, the
third command succeeds with 2052 bytes of payload data (as on the host):
  READ DISC STRUCTURE
  ad 00 00 00 00 00 00 00 08 04 00 00 
  From drive: 2052b
  ...

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

Have a nice day :)

Thomas