Hi,
Stefan Hajnoczi wrote:
> In the future I think it's appropriate to CC qemu-devel since others
> in the community may be interested in virtio-scsi discussions too.
Ok. I'll forward my original mail and this reply to qemu-devel.
> The current state is that CD-ROM passthrough with virtio-scsi does not
> work yet because the in-kernel SCSI target needs a patch to allow the
> GET EVENT STATUS NOTIFICATION command which newish Linux kernel use to
> poll CD-ROMs.
I have the exploration of this command on my own TODO list.
Good to know that it might make problems in the kernel.
--------------------------------------------------------------------------
> In theory QEMU with -drive file=/dev/sg0,if=scsi,... should provide
> SCSI passthrough. QEMU is a userspace process so it uses the
> scsi-generic driver to pass through SCSI commands. You could try that
> (note this is without virtio-scsi and should work today in theory).
The following experiments show quite ill effects.
I could need instructions how to install and use qemu from git
on Debian GNU/Linux 6.0.2 without disturbing the installed
qemu-0.12.5 from apt-get.
Currently i run 0.15.1 from release tarball as
./qemu-0.15.1/i386-softmmu/qemu
with no special indication that this would cause the problems.
The installed 0.12.5 capsizes at the same occasionsi, albeit with
different symptoms.
Nevertheless i get a message at startup
Could not open option rom 'sgabios.bin': No such file or directory
which indicates that this is not the intended way to have a qemu
for testing.
So when i get a git clone, it would be best to have a more
conventional test setup. (Be it only for kvm acceleration.)
--------------------------------------------------------------------------
First try is on qemu-0.15.1:
./qemu-0.15.1/i386-softmmu/qemu \
-nographic \
-m 512 \
-net nic,model=ne2k_pci \
-net user,hostfwd=tcp::5557-:22 \
-hda /dvdbuffer/i386-install.qemu \
-drive file=/dev/sg2,if=scsi,bus=4,unit=0,media=cdrom
Now i have two drives by one option.
xorriso -devices reports
0 -dev '/dev/sr0' rwrw-- : 'TSSTcorp' 'CDDVDW SH-S223B'
1 -dev '/dev/sr1' rwrw-- : 'QEMU ' 'QEMU DVD-ROM'
with /dev/sr1 being an empty drive. (Is this a known bug ?)
But /dev/sr0 seems to work well, on the first glimpse.
Trying to burn something, being logged in via SSH
$ xorriso -dev /dev/sr0 -add /usr/lib
reads old session, adds files, but when writing should begin:
Connection to localhost closed by remote host.
Connection to localhost closed.
and i get the host system prompt.
The window where i ran qemu says:
qemu: ./qemu_dir/qemu-0.15.1/hw/lsi53c895a.c:540:
lsi_do_dma: Assertion `s->current' failed.
----------------------------------------------------------------
With the installed qemu-0.12.5:
kvm \
-nographic \
-m 512 \
-net nic,model=ne2k_pci \
-net user,hostfwd=tcp::5557-:22 \
-hda /dvdbuffer/i386-install.qemu \
-drive file=/dev/sg2,if=scsi,bus=4,unit=0,media=cdrom
The drive shows up, this time as /dev/sr1, but gets temporarily stuck
when i ask it to show the table-of-content.
The stuck SCSI command is
READ DISC STRUCTURE
ad 00 00 00 00 00 00 04 00 04 00 00
... waiting 200 seconds for ioctl(SG_IO) to time out ...
From drive: 4b
00 00 00 00
libburn next tries another READ DISC STRUCTURE with format 0x11 rather
than 0x04, waits another 200 seconds, reads format 0x00, which
succeeds immediately.
The table-of-content looks ok, though. The old session is present,
the new one was not written.
The qemu start window reports each time, when the 200 seconds of
timeout have elapsed:
lsi_scsi: error: Unimplemented message 0x06
lsi_scsi: error: Unimplemented message 0x06
Again i try to burn a session:
$ xorriso -dev /dev/sr1 -add /usr/lib
It reads the old session, adds files, but when writing should begin,
it does not crash qemu but rather stalls.
The whole guest system is incommunicado now. The second SSH session
has stalled, new SSH sessions cannot be initiated.
ssh_exchange_identification: Connection closed by remote host
kvm is running at 100 percent CPU.
After 15 minutes, i killed the kvm process.
An attempt to restart kvm leads to a stalled guest soon after i
logged in via SSH, before i could do anything with the DVD drive.
I see messages
lsi_scsi: error: Unimplemented message 0x06
scsi-generic: Tag 0x0 already in use 0x100cd60
and have to use kill -9 this time.
But a new kvm process appears, cannot be killed, and blocks my
ssh-fowarding port 5557.
I have to reboot the host system, to get rid of that process.
--------------------------------------------------------------
qemu-0.12.5:
I repeated the stuck burn run with xorriso option -scsi_log on.
It stalls after this transaction
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
kvm uses 0 to 1 percent CPU.
After about 3 minutes it is at 100 percent and incommunicado again.
(Trigger might be the 200 seconds timout of the SCSI command.)
Ctrl-a in the start window does not cause any reaction.
It reacts on kill and ends.
An attempt to start qemu-0.15.1 yields a process which consumes
less than 1 percent CPU and does not boot the guest system.
I reboot the host.
--------------------------------------------------------------
Back on qemu-0.15.1 i repeat the table-of-content experiment,
which up to then was only done on qemu-0.12.5.
Same effect. READ DISC STRUCTURE commands with formats 0x04 and 0x11
run into their generous timeout of 200 seconds. Format 0x0 does
not wait for timeout.
Now for the burn run with SCSI log:
It crashes with
./qemu-0.15.1/hw/lsi53c895a.c:540: lsi_do_dma: Assertion `s->current' failed.
at the same command at which 0.12.5 got stuck:
SET STREAMING
b6 00 00 00 00 00 00 00 00 00 1c 00
To drive: 28b
Connection to localhost closed by remote host.
Connection to localhost closed.
--------------------------------------------------------------
qemu-0.15.1:
The poisonous SCSI command shall set the write speed for the
DVD+RW which is in the drive.
It is the first command that tries to send payload data to
the drive (SG_IO dxfer_direction SG_DXFER_TO_DEV). All others
did not involve payload (SG_DXFER_NONE), or they read payload
(SG_DXFER_FROM_DEV).
It is not used with CD-RW. So i try one.
Here the first SG_DXFER_TO_DEV command is
MODE SELECT
55 10 00 00 00 00 00 00 3c 00
To drive: 60b
00 00 00 00 00 00 00 00 05 32 41 c0 00 00 00 00 00 00 00 00
00 00 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+++ sense data = 72 0B 00 06 00 00 00 00
+++ key=B asc=00h ascq=06h ( 4 ms)
This error code means according to MMC-6:
B 00 06 I/O PROCESS TERMINATED
I now see that it hit some other commands. Like:
PREVENT/ALLOW MEDIA REMOVAL
1e 00 00 00 01 00
+++ sense data = 72 0B 00 06 00 00 00 00
+++ key=B asc=00h ascq=06h ( 0 ms)
... several successful transactions happen inbetween ...
SET CD SPEED
bb 00 ff ff 06 e4 00 00 00 00 00 00
+++ sense data = 72 0B 00 06 00 00 00 00
+++ key=B asc=00h ascq=06h ( 4 ms)
libburn tolerates these errors because there is not much use
in handling failed speed settings or a failed tray lock.
Finally the burn run fails because of
WRITE(10)
2a 00 00 00 99 0f 00 00 10 00
+++ sense data = 72 0B 00 06 00 00 00 00
+++ key=B asc=00h ascq=06h ( 0 ms)
Afterwards the CD-RW shows no traces of the burn attempt.
It is still appendable with one recorded session.
The qemu-0.15.1 process and its guest system are still well and
alive. (Different than with DVD+RW and SET STREAMING.)
--------------------------------------------------------------
Have a nice day :)
Thomas
