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

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

i repeated my tests with -drive and -cdrom in the same qemu run:

  ...absolute.path.../x86_64-softmmu/qemu-system-x86_64 \
     -enable-kvm \
     -L ...absolute.path.../pc-bios \
     -nographic \
     -m 512 \
     -net nic,model=ne2k_pci \
     -net user,hostfwd=tcp::5557-:22 \
     -hda /dvdbuffer/i386-install.qemu \
     -drive file=/dev/sg1,if=scsi,media=cdrom \
     -cdrom /dvdbuffer/pseudo_drive

xorriso lists two drives

  0  -dev '/dev/sr0' rwrw-- :  'QEMU    ' 'QEMU DVD-ROM' 
  1  -dev '/dev/sr1' rwrw-- :  'TSSTcorp' 'CDDVDW SH-S223B' 

Both hold a medium now

  Drive current: -dev '/dev/sr0'
  Drive type   : vendor 'QEMU' product 'QEMU DVD-ROM' revision '0.15'
  Media current: CD-ROM
  Media status : is written , is closed
  Media summary: 1 session, 109597 data blocks,  214m data,     0 free

  Drive current: -dev '/dev/sr1'
  Drive type   : vendor 'TSSTcorp' product 'CDDVDW SH-S223B' revision 'SB02'
  Media current: DVD+RW
  Media status : is written , is appendable
  Media summary: 1 session, 16771 data blocks, 32.8m data, 4450m free

(The status "appendable" of DVD+RW is an emulation of xorriso,
 not the result of drive replies.)

The other failures remain, i fear:

Timeouts with
  READ DISC STRUCTURE
  ad 00 00 00 00 00 00 04 00 04 00 00 
  READ DISC STRUCTURE
  ad 00 00 00 00 00 00 11 00 04 00 00
but not with
  READ DISC STRUCTURE 
  ad 00 00 00 00 00 00 00 00 04 00 00  
 
I still get sense code B 00 06 I/O PROCESS TERMINATED with
  PREVENT/ALLOW MEDIA REMOVAL
  1e 00 00 00 01 00
  MODE SELECT 
  55 10 00 00 00 00 00 00 3c 00
  SET STREAMING
  b6 00 00 00 00 00 00 00 00 00 1c 00 
  SET CD SPEED
  bb 00 ff ff 06 e4 00 00 00 00 00 00
  WRITE(10)
  2a 00 00 00 99 0f 00 00 10 00
  SYNCHRONIZE CACHE
  35 02 00 00 00 00 00 00 00 00
  CLOSE TRACK/SESSION
  5b 01 02 00 00 00 00 00 00 00

Good news:
Other than with qemu-0.12.5, the command
  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 
does no crash qemu but only throws B 00 06.
I am using it with -enable-kvm now, to accelerate booting and login.


Do you have a proposal what i should try next ?
(Else i will try to find the code which throws B 00 06.)

Please give me a note, when there are improvements to test.
(Do i get it right, that "git pull" will update my local clone ?
 In my few encounters with git, "git clone" was all i needed.)


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

I have a (weak) argument for making the ATAPI mode page 2A compliant
with MMC-1:
'SanDisk' 'Cruzer', an emulated CD-ROM in a memory stick, throws
random errors if i ask it for 28 bytes rather than the 30 of MMC-1.

Its U3 CD-ROM emulation is not of much importance, as it only
serves to store MS-Windows auto-executables.
Nevertheless, it serves me as example of a poorly programmed
firmware.

I now have to bet on the fact that qemu guest operating systems
tolerate with ATAPI that i request 30 bytes and the drive delivers
only 28.
The only occasion, where i am aware of this assumption to fail, is
Linux 2.4 with USB attached drives.
ATAPI via ide-scsi kernel module did tolerate oversized requests
back in 2007. Since then i did not challenge OSes that way.

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

Have a nice day :)

Thomas