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

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

[Thomas Schmitt]

Hi,

i sent the following to Paolo Bonzini and Stefan Hajnoczi.

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

So i forward my mail to this list.
I am subscribed now.

A first test report of SCSI passthrough without virtio-scsi will
follow soon.

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

Hi,

being unsure whether my cause is appropriate for qemu-devel list,
i write directly to you, who recently discussed virtio-scsi on that
list. If there is a better place, please direct me to it.

I would like to participate as tester in the development of virtio-scsi.
In the october 2011 archive of qemu-devel list, i found a link to
  http://wiki.qemu.org/Features/VirtioSCSI
with
  Status: Under development. Not ready for real-world use yet.
  Features: [...] SCSI passthrough
Is there an outlook when it will be ripe for testing SCSI transactions
with CD-ish drives ?

My goal is to operate a real DVD burner drive from within a Debian
GNU/Linux 6.0.3 i386 as guest on a Debian GNU/Linux 6.0.2 amd64.
The SCSI commands are transported by the guest system via ioctl(SG_IO).
Burn program is xorriso, which uses libburn to communicate with
the drive. I am developer of both, but quite a newbie when it comes
to virtual machines.

I have SCSI specs SPC, SBC, MMC, and some experience in reading and
applying them. I can test with DVD drives at IDE/ATAPI, SATA, and USB
on real installations of GNU/Linux, FreeBSD 8 and OpenSolaris svn 134.
No experience with kernel programming or bus hardware issues.
(libburn is an MMC driver in userspace.)

---------------------------------------------------------------------
What i tried so far:

The qemu version of Debian 6.0.2 is 0.12.5. So i also built 0.15.1 from
the release tarball. I experienced no different behavior, though.

I tried
  -drive file=/dev/sr1,if=virtio,media=cdrom
which yields the same results as -drive if=scsi. (See below.)
Especially the emulated drive identifies itself as
  vendor 'QEMU' product 'QEMU DVD-ROM' revision '0.15'
rather than
  vendor 'TSSTcorp' product 'CDDVDW SH-S223B' revision 'SB02'
of the real one.
Obviously i do not get SCSI passthrough here.

Before this i tried
  -cdrom /dev/sr1
The emulated QEMU DVD-ROM rev 0.12 and rev 0.15 expectedly turned out
to be usable for reading only.

With
  -drive file=/dev/sr1,if=scsi,bus=4,unit=0,media=cdrom
the emulated QEMU DVD-ROM has similar restrictions as with -cdrom,
and additionaly states that there is no medium loaded.
E.g. with this SCSI transaction:
  TEST UNIT READY
  00 00 00 00 00 00 
  +++ sense data = F0 00 02 00 00 00 00 0A 00 00 00 00 3A 00 00 00 00 00
  +++ key=2  asc=3Ah  ascq=00h   (     4 ms)
The block device driver of GNU/Linux sees no medium either:
  dd: opening `/dev/sr0': No medium found
This happens with real /dev/sr1 and with an ISO image in a regular file.

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


Have a nice day :)

Thomas

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

[Thomas Schmitt]

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

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

[Stefan Hajnoczi]

On Tue, Nov 1, 2011 at 9:03 PM, Thomas Schmitt <scdbackup@gmx.net> wrote:
> 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.)

If you want to ensure a self-contained environment try:
qemu-0.15.1/i386-softmmu/qemu -L qemu-0.15.1/pc-bios ...

The -L option sets QEMU's "data_dir" which is used as the base
directory.  There is code to auto-detect but it will prefer the
system-wide /usr/share/qemu path instead of ../pc-bios, so explicitly
setting this option is the right thing to do.

>
> --------------------------------------------------------------------------
>
> 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 ?)

Off the top of my head I'd say this is an empty IDE CD-ROM drive which
is added by default.  Would need to check the code to be sure though.

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

That's a bug in the LSI SCSI HBA emulation or a generic SCSI emulation
problem in QEMU.  I have CCed Paolo and Kevin who have recently been
working on SCSI and IDE much more than me and know more.

> With the installed qemu-0.12.5:

Thanks for the extensive testing.  I actually suggest focussing just
on qemu.git/master because that is where developers mostly invest
their time.  The data points on older versions can be interesting but
my guess is folks won't have time to debug them - instead let's make
qemu.git/master work.

Stefan

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

[Paolo Bonzini]

On 11/02/2011 12:25 PM, Stefan Hajnoczi wrote:
>> 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 ?)
>
> Off the top of my head I'd say this is an empty IDE CD-ROM drive which
> is added by default.  Would need to check the code to be sure though.

Yes, that's correct.

That empty IDE CD-ROM was the same that you were getting with 
virtio-blk.  With virtio-blk you get a /dev/vda drive that will respond 
to SG_IO, so it doesn't look like a pass-through CD-ROM but it is one.

>> 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.
>
> That's a bug in the LSI SCSI HBA emulation or a generic SCSI emulation
> problem in QEMU.  I have CCed Paolo and Kevin who have recently been
> working on SCSI and IDE much more than me and know more.

I suggest trying with 1.0-rc (origin/master).  No guarantee that it 
works, but definitely a lot of bugs have been fixed.  It is also 
possible that a few new ones were introduced.  I can also provide an 
updated version of my vmw_pvscsi device model, which is simpler and more 
stable than the lsi device model.

Also, with 1.0-rc you can do passthrough in two ways: with scsi-generic 
as you did, which always uses SG_IO, and with scsi-block.  scsi-block 
uses read+write for READ/WRITE CDBs and SG_IO for everything else.  You 
can define a scsi-block disk like this:

   -drive file=/dev/sr0,if=none,id=hostcd -device scsi-block,drive=hostcd

The advantage of scsi-block is that it doesn't need a bounce buffer as 
big as the whole request; in virtio-scsi it will not require a bounce 
buffer at all.  From the spec I don't understand how this will fail to 
burn CDs.  It's possible that some modes work and others don't.  I 
planned to test this on test day (Nov 7th).

> Thanks for the extensive testing.  I actually suggest focussing just
> on qemu.git/master because that is where developers mostly invest
> their time.  The data points on older versions can be interesting but
> my guess is folks won't have time to debug them - instead let's make
> qemu.git/master work.

Agreed.

Paolo

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

[Thomas Schmitt]

Hi,

Stefan Hajnoczi wrote:
> I actually suggest focussing just
> on qemu.git/master because that is where developers mostly invest
> their time.

I did now
  git clone git://git.qemu.org/qemu.git
  cd qemu && ./configure && make

I assume this binary is the right one for my "AMD Athlon(tm) II X4 620"
  ./x86_64-softmmu/qemu-system-x86_64
Together with
  -L ...absolute.path.../pc-bios
it still complains on startup
  Could not open option rom 'sgabios.bin': No such file or directory

I cannot spot a file sgabios.bin on the entire host machine by
  find / -name sgabios.bin 2>/dev/null

I repeated the experiments as on qemu-0.15.1. Same results.

If i shall do any further experiments, please give me direct
instructions. (I'm not much accustomed to qemu and git. Assume
that i know nothing beyond what i show here.)


In detail:
----------------------------------------------------------------------

Host system is Debian GNU/Linux 6.0.2 amd64:
  Linux ... 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011 x86_64 GNU/Linux

qemu start command:

  ...absolute.path.../x86_64-softmmu/qemu-system-x86_64 \
     -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

I left out -enable-kvm for now, as i suspect it of causing the bad
effects on the host, which i experienced with qemu-0.12.5.

Guest system is Debian GNU/Linux 6.0.3 i386:
  Linux ... 2.6.32-5-686 #1 SMP Mon Oct 3 04:15:24 UTC 2011 i686

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

Drive list as detected by xorriso:
  0  -dev '/dev/sr0' rwrw-- :  'TSSTcorp' 'CDDVDW SH-S223B' 
  1  -dev '/dev/sr1' rwrw-- :  'QEMU    ' 'QEMU DVD-ROM' 

Inspection:
  Drive type   : vendor 'TSSTcorp' product 'CDDVDW SH-S223B' revision 'SB02'
  Media current: CD-RW
  Media status : is written , is appendable
  Media summary: 1 session, 27783 data blocks, 54.3m data,  626m free

  Drive type   : vendor 'QEMU' product 'QEMU DVD-ROM' revision '0.15'
  Media current: is not recognizable
  Media status : is not present

The emptiness is indicated by GET CONFIGURATION showing no current
profile, and by sense code (2,3A,00) with TEST UNIT READY.
The Linux block device driver comes to the same conclusion:
  dd: opening `/dev/sr1': No medium found

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

Burn attempt on CD-RW:
  xorriso -for_backup -scsi_log on -dev /dev/sr0 -add /usr/lib --
fails and leaves the CD-RW unchanged.
(With CD-RW, qemu does not abort as with DVD+RW.)

Undesirable SCSI transaction outcome with these commands:

  PREVENT/ALLOW MEDIA REMOVAL
  1e 00 00 00 01 00 
  +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00
  +++ key=B  asc=00h  ascq=06h   (     0 ms)

  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 01 00 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 = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00
  +++ key=B  asc=00h  ascq=06h   (     0 ms)

  SET CD SPEED
  bb 00 ff ff 06 e4 00 00 00 00 00 00 
  +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00
  +++ key=B  asc=00h  ascq=06h   (     0 ms)

  WRITE(10)
  2a 00 00 00 99 0f 00 00 10 00 
  +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00
  +++ key=B  asc=00h  ascq=06h   (     4 ms)
(This tried to send 32 kB of data to block 39183 decimal, where the
 new track has to start.)

  SYNCHRONIZE CACHE
  35 02 00 00 00 00 00 00 00 00 
  +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00
  +++ key=B  asc=00h  ascq=06h   (     0 ms)

  CLOSE TRACK/SESSION
  5b 01 02 00 00 00 00 00 00 00 
  +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00
  +++ key=B  asc=00h  ascq=06h   (     0 ms)

The sense code is listed in MMC as:
  B 00 06 I/O PROCESS TERMINATED

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

Now with DVD+RW rather than CD-RW:

The attempt to learn about the medium causes two timeouts after 200
seconds each. (I should reduce the time for these experiments.)
  xorriso -scsi_log on -dev /dev/sr0 -toc

has timeouts with
  READ DISC STRUCTURE
  ad 00 00 00 00 00 00 04 00 04 00 00 
and
  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 
  From drive: 4b
  08 02 00 00 

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

Burn attempt with DVD+RW:
  xorriso -for_backup -scsi_log on -dev /dev/sr0 -add /usr/lib --

with undesirable outcome of

  PREVENT/ALLOW MEDIA REMOVAL
  1e 00 00 00 01 00 
  +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00
  +++ key=B  asc=00h  ascq=06h   (     0 ms)

  SET STREAMING
  b6 00 00 00 00 00 00 00 Connection to localhost closed by remote host.
  Connection to localhost closed.

The qemu start terminal reports
  qemu-system-x86_64: ...absolute.address.../hw/lsi53c895a.c:537:
                      lsi_do_dma: Assertion `s->current' failed.
and the qemu run has aborted.

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

The xorriso program is from the current development tarball (2 MB)
  http://scdbackup.sourceforge.net/xorriso-1.1.7.tar.gz
Buildable by
  tar xzf xorriso-1.1.7.tar.gz
  cd xorriso-1.1.7
  ./configure && make
Executable without installation as
  xorriso/xorriso
Tree size after build is about 20 MB.

See also file ./README
  http://www.gnu.org/s/xorriso/README_xorriso_devel
and man xorriso/xorriso.1
  http://www.gnu.org/s/xorriso/man_1_xorriso_devel.html
as well as the home page
  http://www.gnu.org/s/xorriso

The current release 1.1.6 will not recognize QEMU DVD-ROM because
of its inconsistent Mode Page 2Ah with short Page Length (18 decimal).

----------------------------------------------------------------------
About the non-passthrough QEMU DVD-ROM :

i wrote:
> >   -drive file=/dev/sg2,if=scsi,bus=4,unit=0,media=cdrom
> > Now i have two drives by one option [...]
> > 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 ?)

Stefan Hajnoczi wrote:
> Off the top of my head I'd say this is an empty IDE CD-ROM drive which
> is added by default.  Would need to check the code to be sure though.

Actually i meant:
Is it a known bug that 'QEMU DVD-ROM' is always empty if it stems
from option -drive if=scsi ?
I experience this effect with file=/dev/sr1 as well as with a regular
file as CD drive image. The drive has a medium, if stemming from
option -cdrom.

The fact that 'QEMU DVD-ROM' from file=/dev/sg2,if=scsi behaves like
the drives from the other file=...,if=scsi makes me think that it is
an emulated SCSI drive.

GET CONFIGURATION could tell, if it would deliver feature 0x01.
The 'CDDVDW SH-S223B' reports Physical Interface 7 = "Serial ATAPI".
But the 'QEMU DVD-ROM' does not report feature 0x01.

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

Have a nice day :)

Thomas

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

[Paolo Bonzini]

On 11/02/2011 04:15 PM, Thomas Schmitt wrote:
> Hi,
>
> Stefan Hajnoczi wrote:
>> I actually suggest focussing just
>> on qemu.git/master because that is where developers mostly invest
>> their time.
>
> I did now
>    git clone git://git.qemu.org/qemu.git
>    cd qemu&&  ./configure&&  make
>
> I assume this binary is the right one for my "AMD Athlon(tm) II X4 620"
>    ./x86_64-softmmu/qemu-system-x86_64
> Together with
>    -L ...absolute.path.../pc-bios
> it still complains on startup
>    Could not open option rom 'sgabios.bin': No such file or directory
>
> I cannot spot a file sgabios.bin on the entire host machine by
>    find / -name sgabios.bin 2>/dev/null
>
> I repeated the experiments as on qemu-0.15.1. Same results.
>
> If i shall do any further experiments, please give me direct
> instructions. (I'm not much accustomed to qemu and git. Assume
> that i know nothing beyond what i show here.)

This is a packaging bug, I think.  Will look at it tomorrow.

> Drive list as detected by xorriso:
>    0  -dev '/dev/sr0' rwrw-- :  'TSSTcorp' 'CDDVDW SH-S223B'
>    1  -dev '/dev/sr1' rwrw-- :  'QEMU    ' 'QEMU DVD-ROM'
>
> Burn attempt on CD-RW:
>    xorriso -for_backup -scsi_log on -dev /dev/sr0 -add /usr/lib --
> fails and leaves the CD-RW unchanged.
> (With CD-RW, qemu does not abort as with DVD+RW.)
>
> Undesirable SCSI transaction outcome with these commands:
>
>    PREVENT/ALLOW MEDIA REMOVAL
>    1e 00 00 00 01 00
>    +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00
>    +++ key=B  asc=00h  ascq=06h   (     0 ms)
>
>    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 01 00 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 = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00
>    +++ key=B  asc=00h  ascq=06h   (     0 ms)
>
>    SET CD SPEED
>    bb 00 ff ff 06 e4 00 00 00 00 00 00
>    +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00
>    +++ key=B  asc=00h  ascq=06h   (     0 ms)
>
>    WRITE(10)
>    2a 00 00 00 99 0f 00 00 10 00
>    +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00
>    +++ key=B  asc=00h  ascq=06h   (     4 ms)
> (This tried to send 32 kB of data to block 39183 decimal, where the
>   new track has to start.)
>
>    SYNCHRONIZE CACHE
>    35 02 00 00 00 00 00 00 00 00
>    +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00
>    +++ key=B  asc=00h  ascq=06h   (     0 ms)
>
>    CLOSE TRACK/SESSION
>    5b 01 02 00 00 00 00 00 00 00
>    +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00
>    +++ key=B  asc=00h  ascq=06h   (     0 ms)
>
> The sense code is listed in MMC as:
>    B 00 06 I/O PROCESS TERMINATED

Is it good or bad? :)  I see it even in the very first command.

> The attempt to learn about the medium causes two timeouts after 200
> seconds each. (I should reduce the time for these experiments.)
>    xorriso -scsi_log on -dev /dev/sr0 -toc
>
> has timeouts with
>    READ DISC STRUCTURE
>    ad 00 00 00 00 00 00 04 00 04 00 00
> and
>    READ DISC STRUCTURE
>    ad 00 00 00 00 00 00 11 00 04 00 00

What do these give on the host?  Sounds like another LSI emulation bug.

> The current release 1.1.6 will not recognize QEMU DVD-ROM because
> of its inconsistent Mode Page 2Ah with short Page Length (18 decimal).

The page length is indeed 18 for IDE and 20 for SCSI.  I made some 
changes to that page recently, but left the 18 because I feared causing 
regression.  But if that is a bug, we can probably fix it in 1.0.

> About the non-passthrough QEMU DVD-ROM :
>
> i wrote:
>>>    -drive file=/dev/sg2,if=scsi,bus=4,unit=0,media=cdrom
>>> Now i have two drives by one option [...]
>>> 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 ?)
>
> Stefan Hajnoczi wrote:
>> Off the top of my head I'd say this is an empty IDE CD-ROM drive which
>> is added by default.  Would need to check the code to be sure though.
>
> Actually i meant:
> Is it a known bug that 'QEMU DVD-ROM' is always empty if it stems
> from option -drive if=scsi ?

No, it is not a bug.  Remember this is an IDE DVD-ROM.  It is not 
instantiated by -drive if=scsi: it is the same device that -cdrom 
crsates, only empty because you didn't specify any medium.  You can open 
the tray, close the tray, change the medium with the monitor.

> The fact that 'QEMU DVD-ROM' from file=/dev/sg2,if=scsi behaves like
> the drives from the other file=...,if=scsi makes me think that it is
> an emulated SCSI drive.

It is not, try inspecting /dev/disk and sysfs.  The ATAPI and SCSI code 
is indeed very similar and will be even more similar in 1.0, but for now 
they are distinct.

Paolo

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

[Thomas Schmitt]

Hi,

Paolo Bonzini wrote:
> I suggest trying with 1.0-rc (origin/master).

Am i on the right track with  git clone git://git.qemu.org/qemu.git  ?


> scsi-block uses
> read+write for READ/WRITE CDBs and SG_IO for everything else.

That sounds scary to me. On real Linux systems it is not advisable to
mix SG_IO and block device driver. At least not with optical media.
Often the block device does not learn about status changes until
the tray gets ejected and reloaded manually or by the block device
driver. If i load it by START/STOP UNIT via SG_IO, then the block
device driver believes there are no readable blocks on the medium.

Shall i really try this ?

In my experiments WRITE(10) did fail. But so did other commands.
Critical is most probably the failure of
  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 01 00 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 = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00
  +++ key=B  asc=00h  ascq=06h   (     0 ms)
which shall announce the CD write parameters to the drive (Mode Page 5).
Without it, you have no control and depend on the existence of a
suitable default.

Actually i cannot spot in my experiments a single successful command
with transfer direction to the drive.
READ(10), on the other hand, works well.


Have a nice day :)

Thomas

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

[Paolo Bonzini]

On 11/02/2011 05:26 PM, Thomas Schmitt wrote:
> Hi,
>
> Paolo Bonzini wrote:
>> I suggest trying with 1.0-rc (origin/master).
>
> Am i on the right track with  git clone git://git.qemu.org/qemu.git  ?

Yes.

>> scsi-block uses
>> read+write for READ/WRITE CDBs and SG_IO for everything else.
>
> That sounds scary to me. On real Linux systems it is not advisable to
> mix SG_IO and block device driver. At least not with optical media.
> Often the block device does not learn about status changes until
> the tray gets ejected and reloaded manually or by the block device
> driver. If i load it by START/STOP UNIT via SG_IO, then the block
> device driver believes there are no readable blocks on the medium.

Ah, I didn't know this.  Probably it's because I didn't test on a 
machine with a tray that can load, only a laptop.  We certainly can 
switch more commands from pass-through to emulated (including START/STOP 
UNIT).

Paolo

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

[Thomas Schmitt]

Hi,

i wrote:
> > The sense code is listed in MMC as:
> >    B 00 06 I/O PROCESS TERMINATED

Paolo Bonzini wrote:
> Is it good or bad? :)  I see it even in the very first command.

It does not indicate success. MMC only has the meager info above.

SPC-3 says in table 27 about sense key B:
 "Bh : ABORTED COMMAND: Indicates that the device server aborted
  the command. The application client may be able to recover by
  trying the command again."

It does not come from the real drive, i am very sure.
So unless you find a particular reason in qemu, i doubt that repetition
will help.


> What do these give on the host?  Sounds like another LSI emulation bug.

All is well with the drive on the host.
This is my test machine, which checks build and function of xorriso
with GNU/Linux, FreeBSD 8, and OpenSolaris. It also tested the
freshly released libcdio-0.83 by Rocky Bernstein which uses
on Linux ioctl(CDROM_SEND_PACKET) rather than ioctl(SG_IO).

When i had trouble with vanishing udev links on Debian 6.0.2,
i also tested with wodim. It worked as good as can be expected.


> > The current release 1.1.6 will not recognize QEMU DVD-ROM because
> > of its inconsistent Mode Page 2Ah with short Page Length (18 decimal).

> The page length is indeed 18 for IDE and 20 for SCSI.  I made some changes
> to that page recently, but left the 18 because I feared causing regression.
> But if that is a bug, we can probably fix it in 1.0.

This riddles me.
In hw/scsi-disk.c:mode_sense_page() i see that the page 0x2A
(now MODE_PAGE_CAPABILITIES) gets filled with 22 bytes, compliant
to MMC-1. (Later MMCs have longer minimum sizes.)
But libburn receives only 20 of them, because the Page Length
is reported as 0x12 in the 10th byte of the reply:
  MODE SENSE
  5a 00 2a 00 00 00 00 00 1c 00
  From drive: 28b
  00 22 70 00 00 00 00 00 2a 12 00 00 71 60 29 00 02 c2 00 02
  02 00 02 c2 00 00 00 00
Nevertheless i see in hw/scsi-disk.c
  p[1] = 0x14;
So how is this altered to 0x12 in the further course of processing ?

Further, the Mode Data Length is 0x22, announcing 34 + 2 = 36 overall
bytes in the reply, which matches neither Page Length 0x12 nor 0x14,
but would match Page Length 26 decimal = 0x1a.

A real DVD-ROM drive ('HL-DT-ST' 'DVD-ROM GDR8162B') rather tells
  MODE SENSE
  5a 00 2a 00 00 00 00 00 1c 00
  From drive: 28b
  00 20 41 00 00 00 00 00 2a 18 3f 00 71 73 2b 23 21 13 01 00
  01 00 0d c8 00 00 00 00
so that libburn repeats the transaction with adjusted Allocation Length
  MODE SENSE
  5a 00 2a 00 00 00 00 00 22 00
  From drive: 34b
  00 20 41 00 00 00 00 00 2a 18 3f 00 71 73 2b 23 21 13 01 00
  01 00 0d c8 00 00 00 00 00 00 00 01 00 00

(Some Linux transports react badly if the Allocation Length surpasses
 the actually available amount of bytes. So i adopted this two-step
 strategy, which i learned from growisofs by Andy Polyakov.)


> > Is it a known bug that 'QEMU DVD-ROM' is always empty if it stems
> > from option -drive if=scsi ?
> No, it is not a bug.  Remember this is an IDE DVD-ROM.  It is not
> instantiated by -drive if=scsi: it is the same device that -cdrom crsates,

You are the expert. So i do not contradict.

But it behaves differently. The devices created by -cdrom do have
a medium loaded. The 'QEMU DVD-ROM' from -drive if=scsi have no medium.
(But the other drive 'CDDVDW SH-S223B' from -drive file=/dev/sg1,if=scsi
 has a medium and replies the same as on the host system.)

I just checked with the git clone.
Readable are
  -cdrom /dev/sr0
  -cdrom /dvdbuffer/pseudo_drive  (a regular file)
with dd and with xorriso (via guest SG_IO).

No medium is found in
  -drive file=/dev/sr0,if=scsi,media=cdrom
  -drive file=/dvdbuffer/pseudo_drive,if=scsi,media=cdrom
which report like the /dev/sg1 based 'QEMU DVD-ROM':

No current profile (00 00 in bytes 6 and 7 of reply):
  GET CONFIGURATION
  46 00 00 00 00 00 00 00 14 00 
  From drive: 20b
  00 00 00 10 00 00 00 00 00 00 03 08 00 10 00 00 00 08 00 00

Error condition 2 3A 00 MEDIUM NOT PRESENT on
  TEST UNIT READY
  00 00 00 00 00 00 
  +++ sense data = F0 00 02 00 00 00 00 0A 00 00 00 00 3A 00 00 00 00 00
  +++ key=2  asc=3Ah  ascq=00h   (     4 ms)


> try inspecting /dev/disk and sysfs.  The ATAPI and SCSI code is
> indeed very similar and will be even more similar in 1.0, but for now they
> are distinct.

They are not easy to distinguish since /dev/hdX passed the way.

  $ ls /dev/disk
  ata-QEMU_HARDDISK_QM00001        scsi-SATA_QEMU_HARDDISK_QM00001
  ata-QEMU_HARDDISK_QM00001-part1  scsi-SATA_QEMU_HARDDISK_QM00001-part1
  ata-QEMU_HARDDISK_QM00001-part2  scsi-SATA_QEMU_HARDDISK_QM00001-part2
  ata-QEMU_HARDDISK_QM00001-part5  scsi-SATA_QEMU_HARDDISK_QM00001-part5

With the "-part" suffixes, this does not look like a DVD+RW,
which always only has one logical track.

  $ ls -l /sys/bus/scsi/devices
  total 0
  lrwxrwxrwx 1 root root 0 Nov  2 18:30 0:0:0:0 -> ../../../devices/pci0000:00/0000:00:01.1/host0/target0:0:0/0:0:0:0
  lrwxrwxrwx 1 root root 0 Nov  2 18:30 1:0:0:0 -> ../../../devices/pci0000:00/0000:00:01.1/host1/target1:0:0/1:0:0:0
  lrwxrwxrwx 1 root root 0 Nov  2 18:35 2:0:0:0 -> ../../../devices/pci0000:00/0000:00:04.0/host2/target2:0:0/2:0:0:0
  lrwxrwxrwx 1 root root 0 Nov  2 18:30 host0 -> ../../../devices/pci0000:00/0000:00:01.1/host0
  lrwxrwxrwx 1 root root 0 Nov  2 18:30 host1 -> ../../../devices/pci0000:00/0000:00:01.1/host1
  lrwxrwxrwx 1 root root 0 Nov  2 18:30 host2 -> ../../../devices/pci0000:00/0000:00:04.0/host2
  lrwxrwxrwx 1 root root 0 Nov  2 18:30 target0:0:0 -> ../../../devices/pci0000:00/0000:00:01.1/host0/target0:0:0
  lrwxrwxrwx 1 root root 0 Nov  2 18:30 target1:0:0 -> ../../../devices/pci0000:00/0000:00:01.1/host1/target1:0:0
  lrwxrwxrwx 1 root root 0 Nov  2 18:35 target2:0:0 -> ../../../devices/pci0000:00/0000:00:04.0/host2/target2:0:0

  $ cat /proc/scsi/sg/device_hdr /proc/scsi/sg/devices
  host    chan    id      lun     type    opens   qdepth  busy    online
  0       0       0       0       0       1       1       0       1
  1       0       0       0       5       1       1       0       1
  2       0       0       0       5       1       1       0       1
  thomas@i386:~> cat /proc/scsi/sg/device_strs
  ATA             QEMU HARDDISK           0.15
  QEMU            QEMU DVD-ROM            0.15
  TSSTcorp        CDDVDW SH-S223B         SB02

This is inconclusive, as it lists the hard disk too.

Whatever the reason, there is a problem with -drive if=scsi,medium=cdrom.


Have a nice day :)

Thomas

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

[Paolo Bonzini]

On 11/02/2011 07:05 PM, Thomas Schmitt wrote:
>> >  The page length is indeed 18 for IDE and 20 for SCSI.  I made some changes
>> >  to that page recently, but left the 18 because I feared causing regression.
>> >  But if that is a bug, we can probably fix it in 1.0.
> This riddles me.
> In hw/scsi-disk.c:mode_sense_page() i see that the page 0x2A
> (now MODE_PAGE_CAPABILITIES) gets filled with 22 bytes, compliant
> to MMC-1. (Later MMCs have longer minimum sizes.)

Ok, in your counting I should have written 20 for IDE (0x12 + page 
number + page size) and 22 for SCSI (0x14 + page number + page size).

> But libburn receives only 20 of them, because the Page Length
> is reported as 0x12 in the 10th byte of the reply:
>    MODE SENSE
>    5a 00 2a 00 00 00 00 00 1c 00
>    From drive: 28b
>    00 22 70 00 00 00 00 00 2a 12 00 00 71 60 29 00 02 c2 00 02
>    02 00 02 c2 00 00 00 00
> Nevertheless i see in hw/scsi-disk.c
>    p[1] = 0x14;
> So how is this altered to 0x12 in the further course of processing ?

Because you're using an *IDE* (ATAPI) CD-ROM, not SCSI.  See hw/ide/atapi.c.

Paolo

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

[Thomas Schmitt]

Hi,

i wrote:
> > So how is this altered to 0x12 in the further course of processing ?

Paolo Bonzini wrote:
> Because you're using an *IDE* (ATAPI) CD-ROM, not SCSI.  See hw/ide/atapi.c.

You convinced me.
But this does not explain yet the difference in behavior of
both groups of IDE DVD-ROMs. Why are those of -drive if=scsi empty ?


> Ok, in your counting I should have written 20 for IDE (0x12 + page number +
> page size) and 22 for SCSI (0x14 + page number + page size).

Why the distinction by transport bus ? Mode page 2Ah is a matter
of the drive alone. MMC is independent of the bus.

MMC-1 prescribes Page Length 0x14 = 20.
This counts the bytes after byte 1 of the mode page.
So the page size is 22 bytes.
The last byte is the LSB of Current Write Speed (MMC-1 table 103).

SPC-1 prescribes to prefix the result of MODE SENSE(10) with 8 bytes
of Mode Parameter Header.
The first two are MSB and LSB of Mode Data Length.
  Mode Data Length = 8 + Page Length = 28 = 0x1c
The total size of the reply should be 30 bytes.
Like
  00 1c xx xx xx xx xx xx 2a 14 xx ... up to 30 bytes ...
 
The history of mode page 2Ah is colorful.
In MMC-2, the mode page has 26 bytes rather than 22.
In MMC-3, the length is variable. At least 32 bytes, with the
number of 4-byte write speed descriptors in bytes 30 and 31.
In MMC-4 to MMC-6 it is only briefly mentioned as legacy feature.

Since all MMC drivers have to be aware of MMC-1 compliant drives,
it is well ok to stay with MMC-1, although DVD drives appear first
in MMC-2.

So i would propose to replace 28 by 30, and set buf[28], buf[29] to 0
in hw/ide/atapi.c , cmd_mode_sense() , case MODE_PAGE_CAPABILITIES

I tried to check whether buf[] is large enough in the callers.
With some fgrepping i finally end up in hw/ide/core.c:ide_init1()
    s->io_buffer_total_len = IDE_DMA_BUF_SECTORS*512 + 4;
    s->io_buffer = qemu_memalign(2048, s->io_buffer_total_len);
So roughly this should be ok ... if qemu_memalign() has the job to
allocate at least s->io_buffer_total_len bytes.

I did not yet find out, why the IDE drive emulation emits a Mode Data
Length of 0x22. With Page Length 0x12 it should have been 0x1a.
8 too many.


Have a nice day :)

Thomas

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

[Thomas Schmitt]

Hi,

i forgot to address this concern:

Paolo Bonzini wrote:
> The page length is indeed 18 for IDE and 20 for SCSI.  I made some changes
> to that page recently, but left the 18 because I feared causing regression.
> But if that is a bug, we can probably fix it in 1.0.

The SCSI client is supposed to announce a maximum desired amount of
reply data with MODE SENSE. I see this Allocation Length in use
inside hw/ide/atapi.c:cmd_mode_sense()

      if (buf[0] == GPCMD_MODE_SENSE_10) {
          max_len = ube16_to_cpu(buf + 7);
      } else {
          max_len = buf[4];
      }
      ...
      ide_atapi_cmd_reply(s, 28, max_len);

and

  static void ide_atapi_cmd_reply(IDEState *s, int size, int max_size)
  {
      if (size > max_size)
         size = max_size;

So no driver or application should get overwhelmed by two bytes more
of size, if it correctly submitted its own desired number as Allocation
Length of the commands MODE SENSE(6) or MODE SENSE(10).


Have a nice day :)

Thomas

[Qemu-devel] Compile error

[Frans de Boer]

When compiling QEMU 0.15.x with the option --disable-cpu-emulation, I 
get an abort on fake-exec.c. It can't find the file exec.h.

Any solution/suggestion?

Regards, Frans.

Re: [Qemu-devel] Compile error

[Anthony Liguori]

On 11/02/2011 05:16 PM, Frans de Boer wrote:
>
> When compiling QEMU 0.15.x with the option --disable-cpu-emulation, I get an
> abort on fake-exec.c. It can't find the file exec.h.

QEMU does not have such an option.  You're likely using qemu-kvm.

Regards,

Anthony Liguori

>
> Any solution/suggestion?
>
> Regards, Frans.
>
>

Re: [Qemu-devel] Compile error

[Frans de Boer]

On 11/02/2011 11:19 PM, Anthony Liguori wrote:
> On 11/02/2011 05:16 PM, Frans de Boer wrote:
>>
>> When compiling QEMU 0.15.x with the option --disable-cpu-emulation, I
>> get an
>> abort on fake-exec.c. It can't find the file exec.h.
>
> QEMU does not have such an option. You're likely using qemu-kvm.
>
> Regards,
>
> Anthony Liguori
>
>>
>> Any solution/suggestion?
>>
>> Regards, Frans.
>>
>>
>
>
Yes, your right. I used the wrong list, sorry about that.
Frans.

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

[Paolo Bonzini]

On 11/02/2011 10:22 PM, Thomas Schmitt wrote:
> Hi,
>
> i wrote:
>>> So how is this altered to 0x12 in the further course of processing ?
>
> Paolo Bonzini wrote:
>> Because you're using an *IDE* (ATAPI) CD-ROM, not SCSI.  See hw/ide/atapi.c.
>
> You convinced me.
> But this does not explain yet the difference in behavior of
> both groups of IDE DVD-ROMs. Why are those of -drive if=scsi empty ?

They are not "of -drive if=scsi".  They are "of -cdrom", and unlike the 
SCSI ones they are always present, even if no -cdrom is given (you can 
use -nodefaults to remove all default devices, including the IDE 
CD-ROM).  So if you specified "-drive if=scsi" *and* "-cdrom", you'd get 
two non-empty drives.

>> Ok, in your counting I should have written 20 for IDE (0x12 + page number +
>> page size) and 22 for SCSI (0x14 + page number + page size).
>
> Why the distinction by transport bus ? Mode page 2Ah is a matter
> of the drive alone. MMC is independent of the bus.

It's just an artefact of having two separate implementations for ATAPI 
and SCSI.

> I did not yet find out, why the IDE drive emulation emits a Mode Data
> Length of 0x22. With Page Length 0x12 it should have been 0x1a.
> 8 too many.

Yeah, looks like all the

         case MODE_PAGE_R_W_ERROR: /* error recovery */
             cpu_to_ube16(&buf[0], 16 + 6);

should have "- 2" instead of "+ 6".

Paolo

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

[Thomas Schmitt]

Hi,

first i want to thank Paolo for his patience.

> So if you specified "-drive if=scsi" *and* "-cdrom", you'd get two non-empty
> drives.

Indeed. With
   -drive file=/dev/sr0,if=scsi,media=cdrom -cdrom /dvdbuffer/pseudo_drive
i get two drives with media:

  0  -dev '/dev/sr0' rwrw-- :  'QEMU    ' 'QEMU DVD-ROM' 
  1  -dev '/dev/sr1' rwrw-- :  'QEMU    ' 'QEMU CD-ROM' 

/dev/sr0 is from hw/ide/atapi.c:cmd_mode_sense()
  MODE SENSE
  5a 00 2a 00 00 00 00 00 1c 00 
  From drive: 28b
  00 22 70 00 00 00 00 00 2a 12 3b 00 71 60 2b 00 02 c0 00 02
  02 00 02 c0 00 00 00 00 

/dev/sr1 indeed differs in behavior
  MODE SENSE
  5a 00 2a 00 00 00 00 00 2d 00 
  From drive: 45b
  00 24 00 80 00 00 00 08 00 23 05 40 00 00 08 00 2a 14 3b 00
  7f ff 2f 00 22 60 00 02 08 00 0b 00 00 00 0b 00 0b 00 00 00
  00 00 00 00 00 

Which gives me something to work on. libburn does not take into
respect the Block Descriptor of 8 bytes which sits between
Mode Data Header and mode page.
So it misinterpets the result and demands the wrong Allocation
Length.

This error is explainable by my reading of MMC-5 which prescribes
in table 653:
  "Block Descriptor Length = 0"
MMC-1 on the other hand has in Annex B.4.1 :
  "The Mode Parameter Block Descriptor does not apply to ATAPI
   devices, and the Block Descriptor Length in the Mode
   Parameter Header shall be set to 0."

My thanks to qemu and the developers of its SCSI CD-ROM for showing
me this misconception in libburn.

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

If i do only -drive file=/dev/sr0,if=scsi,medium=cdrom i get
one empty drive, obviously from hw/ide/atapi.c:cmd_mode_sense():

  MODE SENSE
  5a 00 2a 00 00 00 00 00 1c 00 
  From drive: 28b
  00 22 70 00 00 00 00 00 2a 12 3b 00 71 60 29 00 02 c0 00 02
  02 00 02 c0 00 00 00 00 

So i mistook the default DVD-ROM drive, which has no source data and
thus is empty, for the CD-ROM drive which i expected from -drive if=scsi
which would not be empty, but does not show up at all.

The question remains, why the CD-ROM drive is missing if i do -drive
but not -cdrom.

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

I will repeat my experiments with
   -drive file=/dev/sg2,if=scsi,media=cdrom -cdrom /dvdbuffer/pseudo_drive

Maybe the presence of -cdrom cures the problems i had with passthrough.
(The bug in libburn is not to blame for that. The passthrough drive did not
 deliver a block descriptor.)

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

> Yeah, looks like all the
> 
>         case MODE_PAGE_R_W_ERROR: /* error recovery */
>             cpu_to_ube16(&buf[0], 16 + 6);
> should have "- 2" instead of "+ 6".

I came to the same conclusion.


The implementation of MODE SENSE(6) in hw/ide/atapi.c:cmd_mode_sense()
is wrong.

SPC-1, table 239 prescribes only 4 bytes of Mode Parameter Header,
with only one byte of Mode Data Length.

cmd_mode_sense() prepends 8 bytes unconditionally. Suitable only
for MODE SENSE(10).

Obviously nobody ever really needed a correct MODE SENSE(6) with
the emulated IDE CD-ROM of qemu.
MMC-1 allows MODE SENSE(6), MMC-3 implicitely assumes MODE SENSE(10) only,
MMC-5 prescribes to use MODE SENSE(10).

MMC-2 has a list of required ATAPI commands. MODE SENSE(10) is listed.
MODE SENSE(6) is not listed.


I compared this with the SCSI counterpart of cmd_mode_sense():
hw/scsi-disk.c:scsi_disk_emulate_mode_sense()

It distinguishes between MODE_SENSE, which gets 4 bytes of header,
and MODE_SENSE_10, which gets 8. This looks correct.

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

Have a nice day :)

Thomas

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

[Paolo Bonzini]

On 11/03/2011 10:15 AM, Thomas Schmitt wrote:
> Which gives me something to work on. libburn does not take into
> respect the Block Descriptor of 8 bytes which sits between
> Mode Data Header and mode page.
> So it misinterpets the result and demands the wrong Allocation
> Length.
>
> This error is explainable by my reading of MMC-5 which prescribes
> in table 653:
>    "Block Descriptor Length = 0"
> MMC-1 on the other hand has in Annex B.4.1 :
>    "The Mode Parameter Block Descriptor does not apply to ATAPI
>     devices, and the Block Descriptor Length in the Mode
>     Parameter Header shall be set to 0."
>
> My thanks to qemu and the developers of its SCSI CD-ROM for showing
> me this misconception in libburn.

MMC-3 also has some text saying that for compatibility you can have 
block descriptors.

> ------------------------------------------------------------------------
>
> If i do only -drive file=/dev/sr0,if=scsi,medium=cdrom i get
> one empty drive, obviously from hw/ide/atapi.c:cmd_mode_sense():
>
>    MODE SENSE
>    5a 00 2a 00 00 00 00 00 1c 00
>    From drive: 28b
>    00 22 70 00 00 00 00 00 2a 12 3b 00 71 60 29 00 02 c0 00 02
>    02 00 02 c0 00 00 00 00
>
> So i mistook the default DVD-ROM drive, which has no source data and
> thus is empty, for the CD-ROM drive which i expected from -drive if=scsi
> which would not be empty, but does not show up at all.
>
> The question remains, why the CD-ROM drive is missing if i do -drive
> but not -cdrom.

Ok, so we have something to test now. :)

> I will repeat my experiments with
>     -drive file=/dev/sg2,if=scsi,media=cdrom -cdrom /dvdbuffer/pseudo_drive
>
> Maybe the presence of -cdrom cures the problems i had with passthrough.
> (The bug in libburn is not to blame for that. The passthrough drive did not
>   deliver a block descriptor.)

Yes, otherwise it wouldn't be passthrough. :)

> ------------------------------------------------------------------------
>
>> Yeah, looks like all the
>>
>>          case MODE_PAGE_R_W_ERROR: /* error recovery */
>>              cpu_to_ube16(&buf[0], 16 + 6);
>> should have "- 2" instead of "+ 6".
>
> I came to the same conclusion.

Good.

> MMC-1 allows MODE SENSE(6), MMC-3 implicitely assumes MODE SENSE(10) only,
> MMC-5 prescribes to use MODE SENSE(10).
>
> MMC-2 has a list of required ATAPI commands. MODE SENSE(10) is listed.
> MODE SENSE(6) is not listed.
>
>
> I compared this with the SCSI counterpart of cmd_mode_sense():
> hw/scsi-disk.c:scsi_disk_emulate_mode_sense()
>
> It distinguishes between MODE_SENSE, which gets 4 bytes of header,
> and MODE_SENSE_10, which gets 8. This looks correct.

Yep.  Seems easiest to just drop MODE SENSE(6) from ATAPI.

Paolo

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

[Thomas Schmitt]

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

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

[Thomas Schmitt]

Hi,

i could track down the reason for sense code B 00 06 to an ioctl(SG_IO)
which returns -1.  errno is 1.
The host system has in /usr/include/asm-generic/errno-base.h
  #define EPERM            1      /* Operation not permitted */

The user who runs qemu is able to perform e.g. 
  PREVENT/ALLOW MEDIA REMOVAL
  1e 00 00 00 00 00 
via ioctl(SG_IO) on /dev/sg1.
So it can hardly be the permissions of the device file:
  crw-rw---- 1 root cdrom 21, 1 Nov  2 12:44 /dev/sg1
The user is member of group cdrom.

For today, i close my shop. Maybe i get an idea tomorrow, how
to further investigate the problem.

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

B 00 06 comes from hw/scsi-generic.c:scsi_command_complete()

  static void scsi_command_complete(void *opaque, int ret)
  {
  ...
      if (ret != 0) {
          switch (ret) {
          ...
          default:
              status = CHECK_CONDITION;
              scsi_req_build_sense(&r->req, SENSE_CODE(IO_ERROR));

SENSE_CODE is defined in hw/scsi.h
  #define SENSE_CODE(x) sense_code_ ## x

so that SENSE_CODE(IO_ERROR) yields this struct from hw/scsi-bus.c
  /* Command aborted, I/O process terminated */
  const struct SCSISense sense_code_IO_ERROR = {
      .key = ABORTED_COMMAND, .asc = 0x00, .ascq = 0x06
  };


I tried to activate DPRINTF in hw/scsi-generic.c by removing the "//"
before
  #define DEBUG_SCSI

make yields:
  .../hw/scsi-generic.c: In function 'scsi_send_command':
  .../hw/scsi-generic.c:286: error: 'lun' undeclared (first use in this function)
  .../hw/scsi-generic.c:286: error: 'tag' undeclared (first use in this function)

So i had to change in scsi_send_command():

  -     DPRINTF("Command: lun=%d tag=0x%x len %zd data=0x%02x", lun, tag,
  +     DPRINTF("Command: len %zd data=0x%02x",

Further i added DPRINTFs to the suspected thrower of B 00 06:

        if (ret < 0) {
            DPRINTF("scsi_send_command: calling scsi_command_complete(%d)\n", 
                    ret);
            scsi_command_complete(r, ret);
            return 0;
        }
        DPRINTF("scsi_send_command: returning 0\n");

This yields with boot-time command
  1e 00 00 00 00 00 
in the qemu start terminal:

  scsi-generic: Command: len 0 data=0x1e 0x00 0x00 0x00 0x00 0x00
  scsi-generic: scsi_send_command: returning 0
  scsi-generic: scsi_command_complete: ret= -1

I.e. it went through scsi_send_command() and got 0 as return value from
  ret = execute_command(s->conf.bs, r, SG_DXFER_NONE, scsi_command_complete);
Nevertheless there happens a call to scsi_command_complete() with ret==-1.

I added more DPRINTF and printf. 
It turns out that the offending call comes from
  posix-aio-compat.c: posix_aio_process_queue
after the ioctl(SG_IO) failed.

My print points report:
  scsi-generic: Command: len 0 data=0x1e 0x00 0x00 0x00 0x00 0x00
  block.c: bdrv_aio_ioctl: drv= 0x961f00 , drv->bdrv_aio_ioctl= 0x42bc30
  block.c: bdrv_aio_ioctl: drv= 0x9619e0 , drv->bdrv_aio_ioctl= 0x42b2d0
  block/raw-posix.c: hdev_aio_ioctl: calling paio_ioctl()
  scsi-generic: scsi_send_command: returning 0
  posix-aio-compat.c: handle_aiocb_ioctl: ioctl(12, 0x2285, ), ret= -1 , errno= 1
  posix-aio-compat.c: qemu_paio_error: ret= -1
  posix-aio-compat.c: qemu_paio_error: returning 1
  posix-aio-compat.c: posix_aio_process_queue: ret= 1 -> -1
  posix-aio-compat.c: posix_aio_process_queue: calling acb->common.cb(,-1)
  scsi-generic: scsi_command_complete: ret= -1
  scsi-generic: Command complete 0x0x16c0e60 tag=0x0 status=2

ioctl command 0x2285 is defined in /usr/include/scsi/sg.h of host:
  #define SG_IO 0x2285

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

Since i inserted the last few of the new printf() calls, i occasionaly
suffer qemu abort by SIGSEGV during guest boot. It happens before the
first DPRINTF happens in scsi_send_command(). 

But "git diff" reveils no changes towards the original state, which
would be to blame.
The printf format codes and the types match good enough to cause
no warnings at compile time.

Is it a known problem, that adding DPRINTF() or printf() can cause this ?
Or am i just too tired to see my fault ?

+    printf("block.c: bdrv_aio_ioctl: drv= 0x%lx , drv->bdrv_aio_ioctl= 0x%lx\n"
,
+           (unsigned long) drv,
+           (unsigned long) (drv ? drv->bdrv_aio_ioctl : NULL));

+    printf("block/raw-posix.c: hdev_aio_ioctl: calling paio_ioctl()\n");

+            DPRINTF("scsi_command_complete: ret= %d\n", ret);

+        DPRINTF("scsi_read_data: calling scsi_command_complete(%d)\n", ret);

+    DPRINTF("scsi_write_complete: calling scsi_command_complete(%d)\n", ret);

+        DPRINTF("scsi_write_data: calling scsi_command_complete(%d)\n",
+                ret);

+    DPRINTF("Command: len %zd data=0x%02x",
             r->req.cmd.xfer, cmd[0]);

+            DPRINTF("scsi_send_command: calling scsi_command_complete(%d)\n",
+                    ret);

+        DPRINTF("scsi_send_command: returning 0\n");

+    DPRINTF("scsi_send_command: not through execute_command()\n");

+        if(ret)
+           printf("linux-aio.c: qemu_laio_process_completion: ret= %d\n",
+                  ret);

+    if(ret)
+      printf("posix-aio-compat.c: handle_aiocb_ioctl: ioctl(%d, 0x%lx, ), ret= %d , errno= %d\n",
+         aiocb->aio_fildes, (unsigned long) aiocb->aio_ioctl_cmd, ret, errno);

+    if(ret)
+      printf("posix-aio-compat.c: qemu_paio_error: ret= %ld\n", (long int) ret);

+    if(ret)
+      printf("posix-aio-compat.c: qemu_paio_error: returning %ld\n", (long int) ret);

+                    if(ret)
+                      printf("posix-aio-compat.c: posix_aio_process_queue: ret= %d -> %d\n", ret, -ret);

+                if(ret)
+                  printf("posix-aio-compat.c: posix_aio_process_queue: calling acb->common.cb(,%d)\n", ret);

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

Have a nice day :)

Thomas

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

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

[Paolo Bonzini]

On 11/04/2011 10:18 AM, Thomas Schmitt wrote:
>
> Paolo:
> May i ask for the favor that you try to add O_RDWR to the qemu_open()
> call of passthrough devices ?

I think the problem is that you're passing media=cdrom:

     if (media == MEDIA_CDROM) {
         /* CDROM is fine for any interface, don't check.  */
         ro = 1;
     }

Just do not do that when using scsi-generic.

Paolo

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

[Thomas Schmitt]

Hi,

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

Paolo Bonzini wrote:
> I think the problem is that you're passing media=cdrom:
> Just do not do that when using scsi-generic.

The result looks promising, indeed. I disabled my hack but left the
first printf active. Now i see at boot time
  block/raw-posix.c: raw_open_common("/dev/sg2", 1000)
  block/raw-posix.c: raw_open_common("/dev/sg2", 1002)
and still no failing ioctls or sense code B 00 06.

Burning to an appendable CD-RW in mode TAO still works. 

So thanks for this swift fulfilling of my wish. :))

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

Disappointment: 

CD-RW burning in mode SAO (on a blank medium) gets stuck at this command
  SEND CUE SHEET
  5d 00 00 00 00 00 00 00 20 00 
  To drive: 32b
  41 00 00 01 00 00 00 00 41 01 00 10 00 00 00 00 41 01 01 10
  00 00 02 00 41 aa 01 01 00 00 35 30 

After 200 seconds, the qemu process begins to use 100 % CPU,
and the pacifier messages of xorriso stall. The guest is stuck.

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

When i restart qemu and boot the guest without having rebooted the
host, then after about 20 seconds, qemu is at 100 % CPU and no login
is possible. There is a short time window after boot, where i
can log in.

The problem seems to sit in the host's drive /dev/sr1 which
cannot be ejected or used by any program. They all get stuck.
So it is likely that the ungraceful end of drive usage is to blame.

I will tomorrow attach an USB drive to the machine and see
whether re-powering it spares rebooting. (Linux USB is the best
test bed for dangerous drive experiments.)

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

So there are still two show stoppers.

DVD+RW gets stuck at SET STREAMING.
(I will hack libburn to avoid this command and check whether
 writing is possible then. Chances are good, as writing an
 already formatted DVD+RW is quite artless.)

CD SAO gets stuck at SEND CUE SHEET.
(SAO is possible with blank CDs only. It is desirable, because its
 results do not show the traditional read-ahead bug of Linux, which
 is caused by the two non-data sectors at the end of TAO tracks.)


Do you have any hints where i should dig for the special processing
of these commands, which obviously suffer timeout after 200 seconds,
and then drive qemu or the guest into a busily unusable state ?

There must be something about them in qemu. On the host they work
flawlessly.
Both send data, but so do SET CD SPEED, MODE SELECT(10), WRITE(10)
which work fine on the guest.
 
-----------------------------------------------------------------------


Have a nice day :)

Thomas

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

[Paolo Bonzini]

On 11/04/2011 12:09 PM, Thomas Schmitt wrote:
> So there are still two show stoppers.
>
> DVD+RW gets stuck at SET STREAMING.
> (I will hack libburn to avoid this command and check whether
>   writing is possible then. Chances are good, as writing an
>   already formatted DVD+RW is quite artless.)
>
> CD SAO gets stuck at SEND CUE SHEET.
> (SAO is possible with blank CDs only. It is desirable, because its
>   results do not show the traditional read-ahead bug of Linux, which
>   is caused by the two non-data sectors at the end of TAO tracks.)

Is this okay to send to a blank CD with no prior command?  That is, can 
I simply change your SEND CUE SHEET dump to "sg_raw -s" to reproduce?

> Do you have any hints where i should dig for the special processing
> of these commands, which obviously suffer timeout after 200 seconds,
> and then drive qemu or the guest into a busily unusable state ?
>
> There must be something about them in qemu. On the host they work
> flawlessly.
> Both send data, but so do SET CD SPEED, MODE SELECT(10), WRITE(10)
> which work fine on the guest.

I wouldn't be surprised if they are bugs in either scsi-generic or the 
LSI emulation code.  They seem to occur when commands return less data 
than the guest driver has asked; with master I get a guest oops in the 
LSI driver, while the host pads the return data with zeros.  Your READ 
DISC STRUCTURE work for me with my (out-of-tree) vmw_pvscsi emulation.

Paolo

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

[Thomas Schmitt]

Hi,

i wrote:
> > CD SAO gets stuck at SEND CUE SHEET.

Paolo Bonzini wrote:
> I wouldn't be surprised if they are bugs in either scsi-generic or the LSI
> emulation code.  They seem to occur when commands return less data than the
> guest driver has asked; with master I get a guest oops in the LSI driver,
> while the host pads the return data with zeros.  Your READ DISC STRUCTURE
> work for me with my (out-of-tree) vmw_pvscsi emulation.

Please give me instructions for dummies when it is time to
update my current slightly altered git clone, and to repeat
my tests.
(I have the disk space to create a completely new one, if
 this is desirable.)


> Is this okay to send to a blank CD with no prior command?  That is, can I
> simply change your SEND CUE SHEET dump to "sg_raw -s" to reproduce?

You will have to send a mode page 5 at least, which announces
write mode SAO. See MMC-3 6.3.5.

As usual, there is a 8 byte header, followed by the page.

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

Then it should be ok to send

  SEND CUE SHEET
  5d 00 00 00 00 00 00 00 20 00 
  To drive: 32b
  41 00 00 01 00 00 00 00 41 01 00 10 00 00 00 00 41 01 01 10
  00 00 02 00 41 aa 01 01 00 00 35 30 

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

What would have come next:

Above cue sheet promises to the drive, that 4023 * 2048 bytes will
be written by WRITE(10) commands. It will stubbornly wait for all
of them to come. (Maybe you know how to talk the host kernel into
resetting it without rebooting.)

The first write command would have been
  WRITE(10)
  2a 00 ff ff ff 6a 00 00 10 00 
with 32 kiB of payload data. The funny LBA -150 is the start of
the pause track before the data track which starts at LBA 0.
See the notes at the foot of MMC-3 table 281.

>From then on there would be consequtive WRITE(10) commands up to
but not including LBA 3873 decimal.

Finally libburn would have sent
  SYNCHRONIZE CACHE
  35 02 00 00 00 00 00 00 00 00 
and waited for the drive to become ready again.


--------------------------------------------------------------------
Just for reference:
Below this point are only the complete SCSI logs of the real write run
and of the drive inquiry which happend before that write attempt.
--------------------------------------------------------------------

The attempted write run consisted of these commands.
The first mode page 5 (with TAO) is a result of libburn architecture.
The second one orders SAO.

SET CD SPEED
bb 00 ff ff 06 e4 00 00 00 00 00 00 
  1552 ms

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
     0 ms

READ TRACK INFORMATION
52 01 00 00 00 ff 00 00 14 00 
>From drive: 20b
00 1a 01 01 00 00 4f 01 00 00 00 00 00 00 00 00 00 05 7d a7
     4 ms

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 42 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
     4 ms

READ TRACK INFORMATION
52 01 00 00 00 ff 00 00 14 00 
>From drive: 20b
00 1a 01 01 00 00 4f 01 00 00 00 00 00 00 00 00 00 05 7d a7
     0 ms

START/STOP UNIT
1b 01 00 00 01 00 
    64 ms

TEST UNIT READY
00 00 00 00 00 00 
     0 ms

START/STOP UNIT
1b 00 00 00 01 00 
    12 ms

SEND CUE SHEET
5d 00 00 00 00 00 00 00 20 00 
To drive: 32b
41 00 00 01 00 00 00 00 41 01 00 10 00 00 00 00 41 01 01 10
00 00 02 00 41 aa 01 01 00 00 35 30 

This was the last command executed. After the sg_io_hdr.timeout
had elapsed, i saw the increase of host CPU from 1 % to 100 %.

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

Before these command there were several commands for drive and
media inspection

INQUIRY
12 00 00 00 24 00 
>From drive: 36b
05 80 05 32 5b 00 00 00 54 53 53 54 63 6f 72 70 43 44 44 56
44 57 20 53 48 2d 53 32 32 33 42 20 53 42 30 32 
     0 ms

MODE SENSE
5a 00 2a 00 00 00 00 00 1e 00 
>From drive: 30b
00 4a 20 00 00 00 00 00 2a 42 3f 37 f1 7f 29 23 1b 90 01 00
08 00 16 0d 00 10 06 e4 06 e4 
     4 ms

MODE SENSE
5a 00 2a 00 00 00 00 00 4c 00 
>From drive: 76b
00 4a 20 00 00 00 00 00 2a 42 3f 37 f1 7f 29 23 1b 90 01 00
08 00 16 0d 00 10 06 e4 06 e4 00 01 00 00 00 00 06 e4 00 01
00 00 06 e4 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 
     4 ms

GET CONFIGURATION
46 00 00 00 00 00 00 00 08 00 
>From drive: 8b
00 00 01 64 00 00 00 0a 
    20 ms

GET CONFIGURATION
46 00 00 00 00 00 00 01 68 00 
>From drive: 360b
00 00 01 64 00 00 00 0a 00 00 03 38 00 15 00 00 00 16 00 00
00 2b 00 00 00 1b 00 00 00 1a 00 00 00 14 00 00 00 13 00 00
00 12 00 00 00 11 00 00 00 10 00 00 00 0a 01 00 00 09 00 00
00 08 00 00 00 02 00 00 00 01 0b 08 00 00 00 07 01 00 00 00
00 02 07 04 00 00 00 00 00 03 07 04 3b 00 00 00 00 04 08 04
02 00 00 00 00 10 00 08 00 00 08 00 00 00 01 00 00 1d 00 00
00 1e 08 04 03 00 00 00 00 1f 04 04 01 00 01 00 00 20 04 0c
00 00 00 00 00 00 08 00 00 00 01 00 00 21 0d 08 3d 0f 00 01
07 00 00 00 00 23 05 08 00 00 00 00 00 00 00 00 00 24 04 04
80 00 00 00 00 26 00 00 00 27 00 04 00 00 00 00 00 2a 04 04
01 00 00 00 00 2b 00 04 01 00 00 00 00 2c 00 04 03 00 00 00
00 2d 09 04 1f 00 00 00 00 2e 05 04 7f 00 0d 00 00 2f 08 04
4e 00 00 00 00 33 00 08 00 00 00 02 01 10 00 00 00 3b 00 04
01 00 00 00 01 00 03 00 01 01 00 04 00 00 00 00 01 03 00 04
03 00 01 00 01 04 07 04 00 00 00 00 01 05 07 04 00 00 00 00
01 06 00 04 00 00 00 01 01 07 11 04 0f 00 00 00 01 08 03 10
51 39 31 34 36 47 42 53 41 30 38 32 33 32 30 30 01 0a 00 0c
46 44 43 00 53 54 43 00 54 4f 43 00 01 0b 00 04 00 00 00 01
    16 ms

GET PERFORMANCE
ac 00 00 00 00 00 00 00 00 00 03 00 
>From drive: 8b
00 00 00 00 00 00 00 00 
     0 ms

MODE SENSE
5a 00 01 00 00 00 00 00 0c 00 
>From drive: 12b
00 12 20 00 00 00 00 00 01 0a 00 80 
     0 ms

PREVENT/ALLOW MEDIA REMOVAL
1e 00 00 00 00 00 
     0 ms

START/STOP UNIT
1b 00 00 00 03 00 
     0 ms

TEST UNIT READY
00 00 00 00 00 00 
     0 ms

PREVENT/ALLOW MEDIA REMOVAL
1e 00 00 00 01 00 
     4 ms

START/STOP UNIT
1b 01 00 00 01 00 
  1644 ms

TEST UNIT READY
00 00 00 00 00 00 
     0 ms

START/STOP UNIT
1b 00 00 00 01 00 
    20 ms

INQUIRY
12 00 00 00 24 00 
>From drive: 36b
05 80 05 32 5b 00 00 00 54 53 53 54 63 6f 72 70 43 44 44 56
44 57 20 53 48 2d 53 32 32 33 42 20 53 42 30 32 
     0 ms

MODE SENSE
5a 00 2a 00 00 00 00 00 1e 00 
>From drive: 30b
00 4a 20 00 00 00 00 00 2a 42 3f 37 f1 7f 2b 23 1b 90 01 00
08 00 1b 90 00 10 06 e4 06 e4 
     4 ms

MODE SENSE
5a 00 2a 00 00 00 00 00 4c 00 
>From drive: 76b
00 4a 20 00 00 00 00 00 2a 42 3f 37 f1 7f 2b 23 1b 90 01 00
08 00 1b 90 00 10 06 e4 06 e4 00 01 00 00 00 00 06 e4 00 01
00 00 06 e4 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 
     4 ms

GET CONFIGURATION
46 00 00 00 00 00 00 00 08 00 
>From drive: 8b
00 00 01 64 00 00 00 0a 
    16 ms

GET CONFIGURATION
46 00 00 00 00 00 00 01 68 00 
>From drive: 360b
00 00 01 64 00 00 00 0a 00 00 03 38 00 15 00 00 00 16 00 00
00 2b 00 00 00 1b 00 00 00 1a 00 00 00 14 00 00 00 13 00 00
00 12 00 00 00 11 00 00 00 10 00 00 00 0a 01 00 00 09 00 00
00 08 00 00 00 02 00 00 00 01 0b 08 00 00 00 07 01 00 00 00
00 02 07 04 00 00 00 00 00 03 07 04 3b 00 00 00 00 04 08 04
02 00 00 00 00 10 00 08 00 00 08 00 00 00 01 00 00 1d 00 00
00 1e 08 04 03 00 00 00 00 1f 04 04 01 00 01 00 00 20 04 0c
00 00 00 00 00 00 08 00 00 00 01 00 00 21 0d 08 3d 0f 00 01
07 00 00 00 00 23 05 08 00 00 00 00 00 00 00 00 00 24 04 04
80 00 00 00 00 26 00 00 00 27 00 04 00 00 00 00 00 2a 04 04
01 00 00 00 00 2b 00 04 01 00 00 00 00 2c 00 04 03 00 00 00
00 2d 09 04 1f 00 00 00 00 2e 05 04 7f 00 0d 00 00 2f 08 04
4e 00 00 00 00 33 00 08 00 00 00 02 01 10 00 00 00 3b 00 04
01 00 00 00 01 00 03 00 01 01 00 04 00 00 00 00 01 03 00 04
03 00 01 00 01 04 07 04 00 00 00 00 01 05 07 04 00 00 00 00
01 06 00 04 00 00 00 01 01 07 11 04 0f 00 00 00 01 08 03 10
51 39 31 34 36 47 42 53 41 30 38 32 33 32 30 30 01 0a 00 0c
46 44 43 00 53 54 43 00 54 4f 43 00 01 0b 00 04 00 00 00 01
    20 ms

GET PERFORMANCE
ac 00 00 00 00 00 00 00 00 00 03 00 
>From drive: 8b
00 00 00 00 00 00 00 00 
     4 ms

MODE SENSE
5a 00 01 00 00 00 00 00 0c 00 
>From drive: 12b
00 12 20 00 00 00 00 00 01 0a 00 80 
     0 ms

MODE SENSE
5a 00 05 00 00 00 00 00 0a 00 
>From drive: 10b
00 3a 20 00 00 00 00 00 05 32 
     0 ms

GET CONFIGURATION
46 00 00 00 00 00 00 00 08 00 
>From drive: 8b
00 00 01 64 00 00 00 0a 
    20 ms

GET CONFIGURATION
46 00 00 00 00 00 00 01 68 00 
>From drive: 360b
00 00 01 64 00 00 00 0a 00 00 03 38 00 15 00 00 00 16 00 00
00 2b 00 00 00 1b 00 00 00 1a 00 00 00 14 00 00 00 13 00 00
00 12 00 00 00 11 00 00 00 10 00 00 00 0a 01 00 00 09 00 00
00 08 00 00 00 02 00 00 00 01 0b 08 00 00 00 07 01 00 00 00
00 02 07 04 00 00 00 00 00 03 07 04 3b 00 00 00 00 04 08 04
02 00 00 00 00 10 00 08 00 00 08 00 00 00 01 00 00 1d 00 00
00 1e 08 04 03 00 00 00 00 1f 04 04 01 00 01 00 00 20 04 0c
00 00 00 00 00 00 08 00 00 00 01 00 00 21 0d 08 3d 0f 00 01
07 00 00 00 00 23 05 08 00 00 00 00 00 00 00 00 00 24 04 04
80 00 00 00 00 26 00 00 00 27 00 04 00 00 00 00 00 2a 04 04
01 00 00 00 00 2b 00 04 01 00 00 00 00 2c 00 04 03 00 00 00
00 2d 09 04 1f 00 00 00 00 2e 05 04 7f 00 0d 00 00 2f 08 04
4e 00 00 00 00 33 00 08 00 00 00 02 01 10 00 00 00 3b 00 04
01 00 00 00 01 00 03 00 01 01 00 04 00 00 00 00 01 03 00 04
03 00 01 00 01 04 07 04 00 00 00 00 01 05 07 04 00 00 00 00
01 06 00 04 00 00 00 01 01 07 11 04 0f 00 00 00 01 08 03 10
51 39 31 34 36 47 42 53 41 30 38 32 33 32 30 30 01 0a 00 0c
46 44 43 00 53 54 43 00 54 4f 43 00 01 0b 00 04 00 00 00 01
    20 ms

READ DISC INFORMATION
51 00 00 00 00 00 00 00 22 00 
>From drive: 34b
00 20 10 01 01 01 01 00 ff 00 00 00 00 00 00 00 00 61 1a 41
00 4f 3b 4a 00 00 00 00 00 00 00 00 00 00 
     0 ms

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 02 00 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
     0 ms

READ TRACK INFORMATION
52 01 00 00 00 ff 00 00 14 00 
>From drive: 20b
00 1a 01 01 00 00 4f 01 00 00 00 00 00 00 00 00 00 05 7d a7
     4 ms

READ TRACK INFORMATION
52 01 00 00 00 ff 00 00 14 00 
>From drive: 20b
00 1a 01 01 00 00 4f 01 00 00 00 00 00 00 00 00 00 05 7d a7
     0 ms

READ TRACK INFORMATION
52 01 00 00 00 ff 00 00 14 00 
>From drive: 20b
00 1a 01 01 00 00 4f 01 00 00 00 00 00 00 00 00 00 05 7d a7
     0 ms

START/STOP UNIT
1b 01 00 00 00 00 
     4 ms

TEST UNIT READY
00 00 00 00 00 00 
   560 ms

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

Have a nice day :)

Thomas

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

[Andreas Färber]

Hi Thomas,

Am 03.11.2011 23:30, schrieb Thomas Schmitt:
> I tried to activate DPRINTF in hw/scsi-generic.c by removing the "//"
> before
>   #define DEBUG_SCSI
> 
> make yields:
>   .../hw/scsi-generic.c: In function 'scsi_send_command':
>   .../hw/scsi-generic.c:286: error: 'lun' undeclared (first use in this function)
>   .../hw/scsi-generic.c:286: error: 'tag' undeclared (first use in this function)

We're about to release QEMU 1.0(-rc1) and you've just spotted a
compilation issue...

> So i had to change in scsi_send_command():
> 
>   -     DPRINTF("Command: lun=%d tag=0x%x len %zd data=0x%02x", lun, tag,
>   +     DPRINTF("Command: len %zd data=0x%02x",

You've solved this issue 50%! What's missing now is for you to put this
fix into a self-contained patch (without the enabling of DEBUG_SCSI,
etc.) and to submit it using the git-send-email command, so that your
fix can be applied. :)

http://wiki.qemu.org/Contribute/SubmitAPatch

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

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

[Thomas Schmitt]

Hi,

> We're about to release QEMU 1.0(-rc1) and you've just spotted a
> compilation issue...

Maybe one should consider to obtain the missing information
rather than crippling the debug message, like i did.


> You've solved this issue 50%! What's missing now is for you to put this
> fix into a self-contained patch (without the enabling of DEBUG_SCSI,
> etc.) and to submit it using the git-send-email command, so that your
> fix can be applied. :)

Please bear with me. I'm a git noob, who does everything by
try-and-error.
It will be better for everybody, if this patch is generated by
someone who knows what she or he is doing.

I'm still dizzy from drilling a hole into the entrails of qemu
and will have to learn about some compiler tricks which are not
mentioned in my german copy of K&R.
Further, if i learn too much about qemu, then i will lose my
naivity skills as unbiased tester. :))


Have a nice day :)

Thomas

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

[Thomas Schmitt]

Hi,

another showstopper appeared for DVD+RW.

After i disabled SET STREAMING, i was able to write a thoroughly formatted
DVD+RW. But when i inserted one that was never written up to its end, the
attempt failed to (re-)start background formatting (Format Type = 26h):

  FORMAT UNIT
  04 11 00 00 00 00 
  To drive: 12b
  00 02 00 08 ff ff ff ff 98 00 00 01 
  +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00
  +++ key=B  asc=00h  ascq=00h   (   488 ms)

I cannot spot an occurence of this sense code in the qemu sources.
There are B 00 06 , B 29 07 , B 3E 01.

No failed ioctl is reported by my printf.

But the failure happened twice.
After shutdown of the guest (to get access to the drive), i could
format (de-ice) the medium by the host system. Afterwards it was
usable on the booted-again guest.

Currently i suspect that the sense code stems from the guest kernel.
(But caused by some problem with qemu.)


This command can be performed without other preparations.
But its parameters depend on the media state. The one above is
for a partially formatted (i.e. partly written) DVD+RW.

With a completely formatted DVD+RW, the attempt to re-format fails, too:

  FORMAT UNIT
  04 11 00 00 00 00 
  To drive: 12b
  00 02 00 08 ff ff ff ff 98 00 00 00 
  +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00
  +++ key=B  asc=00h  ascq=00h   (   488 ms)

The same command is appropriate for a new, unformatted DVD+RW.
It fails exactly the same way on such a medium. 

The commands here have the Immed bit set (byte 1, bit1 of payload),
so that they should return early. One would watch the drive by
TEST UNIT READY for becomming ready again. REQUEST SENSE with DESC bit
delivers progress information on some drives.
But this is not necessary if FORMAT UNIT already ends with failure
indication.


Have a nice day :)

Thomas

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

[Paolo Bonzini]

On 11/04/2011 09:28 PM, Thomas Schmitt wrote:
>
> After i disabled SET STREAMING, i was able to write a thoroughly formatted
> DVD+RW. But when i inserted one that was never written up to its end, the
> attempt failed to (re-)start background formatting (Format Type = 26h):
>
>    FORMAT UNIT
>    04 11 00 00 00 00
>    To drive: 12b
>    00 02 00 08 ff ff ff ff 98 00 00 01
>    +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00
>    +++ key=B  asc=00h  ascq=00h   (   488 ms)
>
> I cannot spot an occurence of this sense code in the qemu sources.
> There are B 00 06 , B 29 07 , B 3E 01.

Can you retry this running qemu as root or with CAP_SYS_RAWIO?

Paolo

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

[Thomas Schmitt]

Hi,

Paolo Bonzini wrote:
> Can you retry this running qemu as root or with CAP_SYS_RAWIO?

No improvement to see.

On a new DVD+RW i do

  $ xorriso -for_backup -scsi_log on -dev /dev/sr1 -add /usr/include --

and still get

  FORMAT UNIT
  04 11 00 00 00 00 
  To drive: 12b
  00 02 00 08 ff ff ff ff 98 00 00 00 
  +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00
  +++ key=B  asc=00h  ascq=00h   (   484 ms)

The same with an attempt to reformat an already formatted DVD+RW.
  $ xorriso -scsi_log on -dev /dev/sr1 -format full

The same with a write run attempt onto a partially formatted DVD+RW.
The FORMAT UNIT command is slightly different:

  FORMAT UNIT
  04 11 00 00 00 00 
  To drive: 12b
  00 02 00 08 ff ff ff ff 98 00 00 01 
  xorriso : UPDATE : Formatting. Working since 2 seconds
  +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00
  +++ key=B  asc=00h  ascq=00h   (   516 ms)

The same with the attempt to format a sequential DVD-RW (details will be
part of my next report installment about DVD-RW and DVD-R).


qemu start command was:

  .../x86_64-softmmu/qemu-system-x86_64 \
     -L .../pc-bios \
     -enable-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 \
     -cdrom /dvdbuffer/pseudo_drive

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

A passthrough device based on /dev/sr would increase superuser safety.

Running as superuser appears to be quite dangerous in conjunction
with Linux happiness to permutate /dev/sg numbers at boot time.
I first started it with the /dev/sg of the hard disk by mistake.
qemu was stuck at 100% CPU, and the host system did not react on
shutdown -h.
Had to press the hardware reset button. To my luck, it still booted
afterwards.

I now let cdrskin check the /dev/sg file before starting qemu.
So hopefully this will not happen again.
Nevertheless i would prefer to run qemu as normal user.

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

Have a nice day :)

Thomas

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

[Thomas Schmitt]

Hi,

i completed my tests on DVD-RW (next will be DVD+R).

Sequential DVD-RW can be written with write type Incremental (aka Packet)
and be blanked.

The write run commands of this DVD-RW profile 0x14 are the same as the
ones for profile 0x11 DVD-R. So i boldly declare write success for both.

Thoroughly formatted DVD-RW (profile 0x13) can be written. This state
is achieved by formatting and writing data to all blocks (only possible
on the host system for now).

But i have failures with:

- Write type DAO in sequential blank DVD-RW

- Formatting sequential DVD-RW to overwritable profile 0x13

- Expanding of formatted area of a partially formatted DVD-RW

- Inquiring blanking progress by REQUEST SENSE

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

DVD-RW write type DAO makes the guest go stuck.
qemu is on 100 % CPU after:

  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 42 05 08 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 00 00 00 00 00 00 00 00 00 00 00
       0 ms

  READ TRACK INFORMATION
  52 01 00 00 00 01 00 00 14 00 
  From drive: 20b
  00 26 01 01 00 04 41 01 00 00 00 00 00 00 00 00 00 23 12 80
       4 ms

  START/STOP UNIT
  1b 01 00 00 01 00 
  1808 ms

  TEST UNIT READY
  00 00 00 00 00 00 
       0 ms

  START/STOP UNIT
  1b 00 00 00 01 00 

qemu can be killed (no -9 necessary). The drive is accessible by the
host system afterwards. qemu can be restarted and the drive can be used,
without the need for rebooting the host.
So it is not as bad as with CD SAO.

The next command after the stuck START/STOP UNIT would have been RESERVE
TRACK. I suspect that it happened although i did not see its log
message, because the medium is in unhealthy state afterwards.

It pretends to be blank with only 195 MB free and refuses on RESERVE TRACK.
195 MiB is about the expected size of the failed session.

Writing to the medium in this state on the host system made the drive
mad. The drive did not get ready after all data were written. After about
3 minutes it began to make lots of noise. Only reboot did help.
After reboot it was possible to blank the medium, and to write a DAO
session on the host system.

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

The attempt to format a DVD-RW to profile 0x13 "Restricted Overwrite"
fails:

  FORMAT UNIT
  04 11 00 00 00 00 
  To drive: 12b
  00 02 00 08 00 23 10 20 00 00 08 00 
  +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00
  +++ key=B  asc=00h  ascq=00h   (   488 ms)

Formatted DVD-RW behave like DVD+RW, except their hard alignment
constraints to full 32 kiB ECC blocks (this is the "restriction").
They usually have a longer life than sequential DVD-RW.

This FORMAT UNIT command can be performed without special preparations.

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

DVD-RW with profile 0x13 are fully formatted only after they were
entirely overwritten with data. In this case, formatting has to be
restarted before writing further data onto medium.

As the other FORMAT UNIT commands, it fails:

  FORMAT UNIT
  04 11 00 00 00 00 
  To drive: 12b
  00 02 00 08 00 20 71 e0 4c 00 00 10 
  +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00
  +++ key=B  asc=00h  ascq=00h   (   544 ms)

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

REQUEST SENSE does not behave as prescribed for blanking DVD-RW by

  BLANK
  a1 10 00 00 00 00 00 00 00 00 00 00 

MMC-3 5.2 and MMC-5 6.2.3 state about processing of command BLANK with
Immed bit set to one:
"In response to the REQUEST SENSE command, unless an error has occurred,
 the Drive shall return a SK/ASC/ASCQ values set to
 NOT READY/LOGICAL UNIT NOT READY/OPERATION IN PROGRESS,
 with the sense key specific bytes set for progress indication."

But libburn gets on qemu

  TEST UNIT READY
  00 00 00 00 00 00 
  +++ sense data = 71 00 02 00 00 00 00 0A 00 00 00 00 04 08 00 80 24 8B
  +++ key=2  asc=04h  ascq=08h   (     0 ms)

  REQUEST SENSE
  03 00 00 00 12 00 
  From drive: 18b
  f0 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 
       0 ms

It is ok that TEST UNIT READY reports the sense data with
  2 04 08 LOGICAL UNIT NOT READY, LONG WRITE IN PROGRESS
But it is not ok that REQUEST SENSE does not do the same.
On qemu it reports:
  0 00 00 NO ADDITIONAL SENSE INFORMATION

This causes libburn's progress meter to show no progress, although i
can see the two last bytes of the sense data counting upwards.
(0= 0 % done , 65335 = 100 % done)

On the host system, i see:

  TEST UNIT READY
  00 00 00 00 00 00 
  +++ sense data = 71 00 02 00 00 00 00 0A 00 00 00 00 04 08 00 80 00 00
  +++ key=2  asc=04h  ascq=08h   (     4 ms)

  REQUEST SENSE
  03 00 00 00 12 00 
  From drive: 18b
  70 00 02 00 00 00 00 0a 00 00 00 00 04 08 00 80 00 00 
     0 ms
  ...

  REQUEST SENSE
  03 00 00 00 12 00 
  From drive: 18b
  70 00 02 00 00 00 00 0a 00 00 00 00 04 08 00 80 05 ea 
       0 ms

So that xorriso can report:

  xorriso : UPDATE : Blanking  ( 3.3% done in 25 seconds )

The BLANK command can be performed without special preparations.
The medium should not already be blank, though.

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

Have a nice day :)

Thomas

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

[Paolo Bonzini]

On 11/05/2011 03:37 PM, Thomas Schmitt wrote:
> MMC-3 5.2 and MMC-5 6.2.3 state about processing of command BLANK with
> Immed bit set to one:
> "In response to the REQUEST SENSE command, unless an error has occurred,
>   the Drive shall return a SK/ASC/ASCQ values set to
>   NOT READY/LOGICAL UNIT NOT READY/OPERATION IN PROGRESS,
>   with the sense key specific bytes set for progress indication."
>
> But libburn gets on qemu
>
>    TEST UNIT READY
>    00 00 00 00 00 00
>    +++ sense data = 71 00 02 00 00 00 00 0A 00 00 00 00 04 08 00 80 24 8B
>    +++ key=2  asc=04h  ascq=08h   (     0 ms)
>
>    REQUEST SENSE
>    03 00 00 00 12 00
>    From drive: 18b
>    f0 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 00
>         0 ms
>
> It is ok that TEST UNIT READY reports the sense data with
>    2 04 08 LOGICAL UNIT NOT READY, LONG WRITE IN PROGRESS
> But it is not ok that REQUEST SENSE does not do the same.
> On qemu it reports:
>    0 00 00 NO ADDITIONAL SENSE INFORMATION

This is because QEMU always emulates REQUEST SENSE and always returns 
the sense data from the last request.  Is this git master or 0.15?  For 
git master, I would have expected REQUEST SENSE to return the correct 
sense data, but without updating it.

In general, it seems safer (and simpler?) if libburn uses TEST UNIT 
READY and its autosense data to report progress.  REQUEST SENSE would be 
used if SG_IO reports CHECK CONDITION without SG_ERR_DRIVER_SENSE (but 
modern OSes will always emulate autosense even if the HBA does not 
support it) and possibly if TEST UNIT READY returns GOOD which is 
allowed by deprecated in MMC.

Paolo

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

[Thomas Schmitt]

Hi,

> > [REQUEST SENSE while blanking]
> > MMC-3 5.2 and MMC-5 6.2.3

> Is this git master or 0.15? 

It is a git clone obtained on November 2 by
  git clone git://git.qemu.org/qemu.git

I see a file VERSION with date Nov 2 13:41 (+0100)

  $ cat VERSION
  0.15.90

  $ git describe
  fatal: No annotated tags can describe 'e072ea2fd8fdceef64159b9596d3c15ce01bea91'.
  However, there were unannotated tags: try --tags.

  $ git describe --tags
  v1.0-rc0


Should i run
  git pull git://git.qemu.org/qemu.git
? (My clone is still slightly altered. Will this be a problem ?)


> This is because QEMU always emulates REQUEST SENSE and always returns the
> sense data from the last request.

Is this realistic enough for passthrough ?
Shouldn't qemu forward all SCSI commands to the host operating system
in this case ?


> REQUEST SENSE would be used if
> SG_IO reports CHECK CONDITION without SG_ERR_DRIVER_SENSE (but modern OSes
> will always emulate autosense even if the HBA does not support it) and
> possibly if TEST UNIT READY returns GOOD which is allowed by deprecated in
> MMC.

Up to now it appeared better to use the explicitely prescribed
method with REQUEST SENSE.
It is not a showstopper anyway. Just a little beauty flaw.
There are also some drives which do not report proper progress.

I have this topic on my todo list, together with a more graceful
handling if SET STREAMING fails.

Currently i am at the item
 - Test all libburn write models of CD, DVD, and BD.
   Write a summary of all results.

I plan to check DVD+R tonight. BD-R and BD-RE tomorrow.


Have a nice day :)

Thomas

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

[Thomas Schmitt]

Hi,

now for DVD+R burning.

It works well if i avoid command RESERVE TRACK.

RESERVE TRACK shows similar effects as the failed DVD-RW DAO run,
resp. the failed CD SAO run: qemu gets stuck at 100 % CPU.
No failed ioctl is indicated by my printfs.


Details:

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

As with all DVD types, READ DISC STRUCTURE formats 0x04 and 0x11 block
until timeout.
I disable them for these tests.

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

Blank DVD+R

  $ xorriso -for_backup -scsi_log on -dev /dev/sr1 -add /usr/include --

makes the guest system block 11 seconds after
  RESERVE TRACK
  53 00 00 00 00 00 00 0f 30 00 

CPU 100 % , no life in SSH sessions.

After killing qemu, the drive is usable from the host system.
A track is reserved, no data were written.

I could write another track to it, by avoiding RESERVE TRACK.
But now libburn is lost in the woods. It wanted to close the session,
but the first empty track causes this to fail.

I will later have to try to write and close the first track.
For now the medium is spoiled.

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

New DVD+R. This time no RESERVE TRACK.
For that i have to avoid that xorriso learns the size of the session
in advance. Thus the cdrtools usage model: 

  $ xorriso -as mkisofs -graft-points /usr/include=/usr/include \
            --for_backup \
    | xorriso -as cdrecord dev=/dev/sr1 -v -V -waiti -multi -

This yields a readable track. I get a credible table-of-content.
MD5 sums of files match correctly.

Another session can be added cdrtools style.
All is well. Table-of-content is readable, MD5 sums match.

I add a third session, and order the medium to be closed, by omitting
cdrecord option -multi.
Works well. Passes all read checks.

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

Since BD-R are very similar to DVD+R, but much more expensive,
i will tomorrow only test the case without RESERVE TRACK.


Have a nice day :)

Thomas

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

[Paolo Bonzini]

On 11/05/2011 09:47 PM, Thomas Schmitt wrote:
> Since BD-R are very similar to DVD+R, but much more expensive,
> i will tomorrow only test the case without RESERVE TRACK.

Yeah, I don't think it's necessary.

It would be more interesting if you tried again the failure cases with a 
virtio drive (if=virtio).  It would appear as /dev/vda but you can issue 
SG_IO to it.  This would isolate the failure to the kernels vs. the SCSI 
subsystem.

Paolo

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

[Thomas Schmitt]

Hi,

i wanted to test Blu-ray burning and attached a BD recorder via USB
to the host. Its power was switched on, before i booted the host.

The host can operate this drive.
But the qemu guest obviously has severe problems with it.

There is a 'QEMU DVD-ROM' at /dev/sr0.
There is also a /dev/sr1, which does not show up in the udev file
  /etc/udev/rules.d/70-persistent-cd.rules 
which usually reacts on new drives. 
Neither the superuser (nor the normal user after chmod a+rw) can
operate /dev/sr1.
xorriso gets

  INQUIRY
  12 00 00 00 24 00 
  +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00
  +++ key=B  asc=00h  ascq=06h   ( 30992 ms)

and my qemu printf reports

  posix-aio-compat.c: handle_aiocb_ioctl: ioctl(12, 0x2285, ),
                      ret= -1 , errno= 19

That's ENODEV /* No such device */.

Note well, that for having a failing iotcl() i first had to open the
device file successfully.
So "No such device" is probably related to an unprovoked re-attaching
of the drive which i found in the host system log. (See below.)

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

When i shutdown the guest system, the host got a kernel Oops.
All my SSH sessions on the host are frozen.
Except a session which ran top, they all display:

  Message from syslogd@debian2 at Nov  6 08:47:42 ...
   kernel:[ 1961.576375] Oops: 0000 [#1] SMP 

  Message from syslogd@debian2 at Nov  6 08:47:42 ...
   kernel:[ 1961.576382] last sysfs file: /sys/devices/pci0000:00/0000:00:12.0/usb3/3-3/3-3:1.0/host9/target9:0:0/9:0:0:0/block/sr2/removable

  Message from syslogd@debian2 at Nov  6 08:47:42 ...
   kernel:[ 1961.576598] Stack:

  Message from syslogd@debian2 at Nov  6 08:47:42 ...
   kernel:[ 1961.576630] Call Trace:

  Message from syslogd@debian2 at Nov  6 08:47:42 ...
   kernel:[ 1961.576748] Code: 48 8b 47 18 48 8b 00 48 8b 40 60 48 85 c0 74 06 49 89 c3 41 ff e3 48 c7 86 a0 00 00 00 00 00 00 00 31 c0 c3 48 8b 47 18 48 8b 00 <48> 8b 40 68 48 85 c0 74 09 48 89 f7 49 89 c3 41 ff e3 c3 48 8b 

  Message from syslogd@debian2 at Nov  6 08:47:42 ...
   kernel:[ 1961.576824] CR2: 0000000000000068

Funnily the graphical login screen of the host did still react on the
keyboard but froze after i entered the desktop user password.

I had to press the hardware reset button.

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

The qemu start command is the same as with the previous successful runs.
Only the /dev/sg address differs.
I double checked before starting qemu, it is the right /dev/sg for the
drive.

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

qemu was started by a normal user, not by the superuser.

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

The drive is an

  'Optiarc' 'BD RW BD-5300S' revision '1.04'

attached via SATA to an USB box "Delock 5.25 inch enclosure eSATA/USB".

  Nov  6 08:15:06 debian2 kernel: [    1.294442] usb 1-3: Product: JM20336 SATA, USB Combo
  Nov  6 08:15:06 debian2 kernel: [    1.294444] usb 1-3: Manufacturer: JMicron
  Nov  6 08:15:06 debian2 kernel: [    1.294445] usb 1-3: SerialNumber: 306663601043

The drive attachment messages first talk of "8:0:0:0"

  Nov  6 08:15:06 debian2 kernel: [    6.301719] scsi 8:0:0:0: CD-ROM            Optiarc  BD RW BD-5300S   1.04 PQ: 0 ANSI: 0
  Nov  6 08:15:06 debian2 kernel: [    6.310686] sr2: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
  Nov  6 08:15:06 debian2 kernel: [    6.310868] sr 8:0:0:0: Attached scsi generic sg3 type 5

and later of "9:0:0:0" after a disconnect which i cannot relate
to a physical event on bus or power supply:
 
  Nov  6 08:35:31 debian2 kernel: [ 1232.103847] usb 1-3: USB disconnect, address 3
  Nov  6 08:35:31 debian2 kernel: [ 1232.111661] sg_rq_end_io: device detached
  Nov  6 08:35:32 debian2 kernel: [ 1233.480103] usb 1-3: new high speed USB device using ehci_hcd and address 5
  Nov  6 08:35:33 debian2 kernel: [ 1233.976106] usb 3-3: new full speed USB device using ohci_hcd and address 3
  Nov  6 08:35:33 debian2 kernel: [ 1234.135535] usb 3-3: not running at top speed; connect to a high speed hub
  Nov  6 08:35:33 debian2 kernel: [ 1234.147516] usb 3-3: New USB device found, idVendor=152d, idProduct=2336
  Nov  6 08:35:33 debian2 kernel: [ 1234.147525] usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=5
  Nov  6 08:35:33 debian2 kernel: [ 1234.147531] usb 3-3: Product: JM20336 SATA, USB Combo
  Nov  6 08:35:33 debian2 kernel: [ 1234.147536] usb 3-3: Manufacturer: JMicron
Nov  6 08:35:33 debian2 kernel: [ 1234.147540] usb 3-3: SerialNumber: 306663601043
  Nov  6 08:35:33 debian2 kernel: [ 1234.147752] usb 3-3: configuration #1 chosen from 1 choice
  Nov  6 08:35:33 debian2 kernel: [ 1234.153804] scsi9 : SCSI emulation for USB Mass Storage devices
  Nov  6 08:35:38 debian2 kernel: [ 1239.163858] scsi 9:0:0:0: CD-ROM            Optiarc  BD RW BD-5300S   1.04 PQ: 0 ANSI: 0
  Nov  6 08:35:38 debian2 kernel: [ 1239.173821] sr2: scsi3-mmc drive: 125x/125x writer dvd-ram cd/rw xa/form2 cdda tray
 Nov  6 08:35:38 debian2 kernel: [ 1239.174216] sr 9:0:0:0: Attached scsi generic sg4 type 5

This might have been the moment when i first accessed the drive from
within the guest. The timestamp is a bit late for the qemu start.
It is too early for the Oops and my graphical login attempt.

It would match somehow above "No such device" message of qemu
  posix-aio-compat.c: handle_aiocb_ioctl: ioctl(12, 0x2285, ),
                      ret= -1 , errno= 19

In any case the host switched the drive from sg3 to sg4, while qemu was
told to use it as sg3.

The next lines in the log are those from Oops event:

  Nov  6 08:47:42 debian2 kernel: [ 1961.576365] PGD 11894c067 PUD 118964067 PMD 0 
  Nov  6 08:47:42 debian2 kernel: [ 1961.576391] CPU 0
  Nov  6 08:47:42 debian2 kernel: [ 1961.576395] Modules linked in: sco powernow_k8 ppdev lp cpufreq_powersave bridge cpufreq_stats stp bnep cpufreq_conservative rfcomm cpufreq_userspace l2cap crc16 bluetooth rfkill kvm_amd kvm binfmt_misc fuse loop snd_hda_codec_atihdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq snd_timer snd_seq_device snd radeon ttm drm_kms_helper soundcore drm i2c_algo_bit i2c_piix4 shpchp snd_page_alloc i2c_core k10temp pci_hotplug edac_core edac_mce_amd evdev parport_pc parport button pcspkr processor ext3 jbd mbcache usbhid hid sg sr_mod sd_mod crc_t10dif cdrom ata_generic usb_storage ahci ohci_hcd thermal pata_atiixp libata ehci_hcd r8169 mii scsi_mod usbcore nls_base thermal_sys [last unloaded: scsi_wait_scan]
  Nov  6 08:47:42 debian2 kernel: [ 1961.576508] Pid: 15, comm: events/0 Not tainted 2.6.32-5-amd64 #1 GA-MA74GM-S2H
  Nov  6 08:47:42 debian2 kernel: [ 1961.576515] RIP: 0010:[<ffffffff81176533>]  [<ffffffff81176533>] elv_put_request+0x7/0x1a
  Nov  6 08:47:42 debian2 kernel: [ 1961.576528] RSP: 0018:ffff880127ac5db8  EFLAGS: 00010006
  Nov  6 08:47:42 debian2 kernel: [ 1961.576533] RAX: 0000000000000000 RBX: ffff8801100cfce0 RCX: 000000000000087d
  Nov  6 08:47:42 debian2 kernel: [ 1961.576539] RDX: ffff880124f62b80 RSI: ffff8801100cfce0 RDI: ffff880123fc11a0
  Nov  6 08:47:42 debian2 kernel: [ 1961.576545] RBP: 0000000001082c40 R08: ffff880127ac4000 R09: ffff880005215780
  Nov  6 08:47:42 debian2 kernel: [ 1961.576551] R10: ffff88012775a0c0 R11: ffff88012609cde8 R12: ffff880123fc11a0
  Nov  6 08:47:42 debian2 kernel: [ 1961.576556] R13: 0000000000000282 R14: ffff880127ac8000 R15: ffff880127ac8000
  Nov  6 08:47:42 debian2 kernel: [ 1961.576564] FS:  00007fb63e148700(0000) GS:ffff880005200000(0000) knlGS:0000000000000000
  Nov  6 08:47:42 debian2 kernel: [ 1961.576570] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
  Nov  6 08:47:42 debian2 kernel: [ 1961.576575] CR2: 0000000000000068 CR3: 00000001189f4000 CR4: 00000000000006f0
  Nov  6 08:47:42 debian2 kernel: [ 1961.576581] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  Nov  6 08:47:42 debian2 kernel: [ 1961.576587] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
  Nov  6 08:47:42 debian2 kernel: [ 1961.576594] Process events/0 (pid: 15, threadinfo ffff880127ac4000, task ffff880127ac8000)
  Nov  6 08:47:42 debian2 kernel: [ 1961.576602]  ffffffff8117e967 ffff880123fc11a0 0000000000000000 ffff8801100cfce0
  Nov  6 08:47:42 debian2 kernel: [ 1961.576610] <0> ffffffff8117ef14 ffff88012600e078 ffff88012600e000 ffff88012600f290
  Nov  6 08:47:42 debian2 kernel: [ 1961.576620] <0> ffffffffa00f775e ffff88012600f288 ffff88012600e000 ffff880123da86c0
  Nov  6 08:47:42 debian2 kernel: [ 1961.576640]  [<ffffffff8117e967>] ? __blk_put_request+0x7b/0xb0
  Nov  6 08:47:42 debian2 kernel: [ 1961.576649]  [<ffffffff8117ef14>] ? blk_put_request+0x26/0x3a
  Nov  6 08:47:42 debian2 kernel: [ 1961.576663]  [<ffffffffa00f775e>] ? sg_finish_rem_req+0x5e/0xda [sg]
  Nov  6 08:47:42 debian2 kernel: [ 1961.576675]  [<ffffffffa00f7821>] ? sg_remove_sfp_usercontext+0x1c/0xbb [sg]
  Nov  6 08:47:42 debian2 kernel: [ 1961.576675]  [<ffffffffa00f7821>] ? sg_remove_sfp_usercontext+0x1c/0xbb [sg]
  Nov  6 08:47:42 debian2 kernel: [ 1961.576686]  [<ffffffff810618e7>] ? worker_thread+0x188/0x21d
  Nov  6 08:47:42 debian2 kernel: [ 1961.576697]  [<ffffffffa00f7805>] ? sg_remove_sfp_usercontext+0x0/0xbb [sg]
  Nov  6 08:47:42 debian2 kernel: [ 1961.576706]  [<ffffffff81064f1a>] ? autoremove_wake_function+0x0/0x2e
  Nov  6 08:47:42 debian2 kernel: [ 1961.576715]  [<ffffffff8106175f>] ? worker_thread+0x0/0x21d
  Nov  6 08:47:42 debian2 kernel: [ 1961.576721]  [<ffffffff81064c4d>] ? kthread+0x79/0x81
  Nov  6 08:47:42 debian2 kernel: [ 1961.576731]  [<ffffffff81011baa>] ? child_rip+0xa/0x20
  Nov  6 08:47:42 debian2 kernel: [ 1961.576738]  [<ffffffff81064bd4>] ? kthread+0x0/0x81
  Nov  6 08:47:42 debian2 kernel: [ 1961.576744]  [<ffffffff81011ba0>] ? child_rip+0x0/0x20
  Nov  6 08:47:42 debian2 kernel: [ 1961.576821]  RSP <ffff880127ac5db8>
  Nov  6 08:47:42 debian2 kernel: [ 1961.576830] ---[ end trace c4a3be0d337e533d ]---

Then come lines from the reboot:
  Nov  6 08:56:19 debian2 kernel: imklog 4.6.4, log source = /proc/kmsg started.

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

I will now try to attach the drive via eSATA.


Have a nice day :)

Thomas

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

[Thomas Schmitt]

Hi,

Paolo Bonzini wrote:
> It would be more interesting if you tried again the failure cases with a
> virtio drive (if=virtio).  It would appear as /dev/vda but you can issue
> SG_IO to it.  This would isolate the failure to the kernels vs. the SCSI
> subsystem.

Will do. I am currently fighting with eSATA and may have to give up
the planned Blu-ray tests, after USB already failed so dramatically.

The external drive does not work properly with 3.0 Gbps.
This is a known shortcomming of my test machine's eSATA cabling or of
the eSATA box (i only have one of either kind, so i cannot cross-check).

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

Interesting insight:

The failure at 3.0 Gbps throws on the host the same sense code as
FORMAT UNIT does on the guest with the internal SATA drive, which
runs at 1.5 Gbps by miracle.
  Sense Key B "Command aborted", ASC 00 ASCQ 00

So the sense code with FORMAT UNIT might stem from the host kernel
and not from qemu.

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

Other than Debian 5 the newer Debian 6 kernel 2.6.32-5-amd64 does not
reset to 1.5 Gps after the first transport failure.
  Nov  6 10:59:55 debian2 kernel: [ 2025.849176] ata5: hard resetting link
  Nov  6 10:59:56 debian2 kernel: [ 2026.780105] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
I dimly remember that i'd need to patch initrd to get the kernel
module option into effect at an early boot stage.
I haven't done this since two years and this could possibly change the
whole test setup.

Better would be to know, why the internal SATA drive is started with
1.5 Gbps at boot time
  Nov  6 10:26:15 debian2 kernel: [    1.241546] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
  Nov  6 10:26:15 debian2 kernel: [    1.242406] ata3.00: ATAPI: TSSTcorp CDDVDW SH-S223B, SB02, max UDMA/100

In contrast to the eSATA attached drive
  Nov  6 10:26:15 debian2 kernel: [    1.688050] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
  Nov  6 10:26:15 debian2 kernel: [    1.693623] ata5.00: ATAPI: Optiarc BD RW BD-5300S, 1.04, max UDMA/100

On Debian 5, the internal drive was run with 3.0 Gbps and worked fine.

Miracles of system administration ...

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


Have a nice day :)

Thomas

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

[Thomas Schmitt]

Hi,

i have finished CD and DVD tests with
  drive file=/dev/sg2,if=virtio -cdrom /dvdbuffer/pseudo_drive

There is substantial improvement towards if=scsi.

Actually everything works like a charm now. :))

It did not work for libburn out of the box, but i could work around
most of the obstacles.
Only remaining obstacle for normal usage: How to use the drive as
block device for reading ?
/dev/vda behaves like /dev/sg, not like /dev/sr.
  $ cat /dev/vda | wc
      0       0       0
(xorriso has no problem to read the media, because it does its
 entire drive i/o via libburn's MMC capabilities.)

I did not retry the USB drive. Will do tomorrow.
All SCSI commands, which get used with BD-R and BD-RE, should be
already tested now, nevertheless. BD-R are much like DVD+R, BD-RE
resemble DVD+RW.


Following is a preliminary summary of successes, an observation about
SSH reactivity, a proposal to curb file=/dev/sg*,if=scsi, and a report
about my workarounds to talk libburn into using /dev/vda.

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

Success with formerly successful use cases:

  All media types
  
    Tray loading and ejecting.

  CD-RW (and most probably CD-R)

    Writing a session with a single track with write type TAO.
    As first session and as add-on session.

  DVD+RW

    Writing to thoroughly formatted DVD+RW.

  DVD-RW (and most probably DVD-R)

    Writing with write type Incremental (aka Packet), multiple sessions.

    Blanking.

    Writing to thoroughly formatted DVD-RW.

  DVD+R

    Writing sessions without using RESERVE TRACK.

    Closing of medium.

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

Success with formerly failing or partially failing use cases:

  CD-RW (and most probably CD-R)

    Burning a CD SAO session
    Was: * DRIVE FREEZER, GUEST KILLER  
         Writing a first session to blank media with write type SAO.
         The guest freezes. The drive gets unusable by the host system
         until host reboot. Offending command:  SEND CUE SHEET

  DVD in general

    Telling the drive the desired DVD write speed with DVD+RW, DVD-RW
    (and most probably DVD-R), DVD+R
    Was: * DRIVE FREEZER, GUEST KILLER
         Guest freezes, qemu goes to 100% CPU, after SET STREAMING

    Media inquiry without blocking out any READ DISC STRUCTURE command.
    Was: * ANNOYING
         Guest SG_IO timeout with READ DISC STRUCTURE formats
         0x04 , 0x11 , 0x0e , 0x10.

  DVD+RW

    Writing to partly formatted DVD+RW and new unformatted DVD+RW.
    Was: SHOWSTOPPER
         Failure to write to unformatted or partly formatted DVD+RW.
         Offending command: FORMAT UNIT

  DVD-RW 

    Writing with write type DAO to blank sequential DVD-RW.
    Was: * GUEST KILLER
         Guest freezes with DVD-RW write type DAO. qemu is on 100 % CPU.
         Most probably after RESERVE TRACK, although this command is not shown
         by the SCSI log. But the command before it is shown and the medium
         has inconsistent knowledge of the desired track size.

    Formatting DVD-RW from sequential profile 0x14 to overwritable profile
    0x13.
    Was: * ANNOYING 
         Failure to format sequential DVD-RW, and to write to partially
         formatted DVD-RW.

    libburn shows progress with asynchronous BLANK and FORMAT UNIT.
    Was: * UGLY
         Failure to deliver progress of Blanking DVD-RW via REQUEST SENSE.

  DVD+R

    Writing a DVD+R session with RESERVE TRACK    
    Was: * GUEST KILLER MEDIUM KILLER
         Guest freezes, medium has unwritten open reserved track after
         RESERVE TRACK

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

Success with use cases not yet tried with if=scsi :

  CD-RW

    Blanking in mode fast.

    Closing CD-RW after writing a TAO session.

  DVD-RW (and most probably DVD-R)

    Closing DVD-RW after an Incremental session.

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

Observation:

  Now that everything works so well, i try multi-tasking.
  It appears that the SSH session is hampered for the time when
  longer SCSI transactions are waiting for the drive reply.
  E.g. when TEST UNIT READY needs 1600 milliseconds to tell that the
  drive is not ready.
  At the same time, the input line of another SSH session does not
  swiftly echo my toggling. It is not completely dead, but very slow.
  E.g. i get two single characters with two feelable delays and then
  all is normal again.
  I believe this is also the reason why i did not see the log message
  of the RESERVE track of the failed DAO run on if=scsi.

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

Proposal:

  As long as file=/dev/sg*,if=scsi is such a mine field, one should
  consider to disable it with CD-ish drives unless a special option
  is given at qemu start.

-----------------------------------------------------------------------
Obstacles and workarounds with if=virtio :

The device file /dev/vda does not support
  ioctl(fd, SG_GET_SCSI_ID, &sid);
or
  ioctl(fd, CDROM_DRIVE_STATUS, 0);
but rather on both returns -1 with errno 25
  ENOTTY   /* Not a typewriter */

Therefore libburn cannot confirm that this is indeed a CD drive.

I have to cheat libburn by a soft link /dev/sr1 and by a little hack
in the source code, before it is willing to send SCSI commands other
than TEST UNIT READY to this drive. (Will have to make libburn trust
the first byte from command INQUIRY which is 0x05 = "CD/DVD device"
according to SPC-3 table 83.)
I also made /dev/vda accessible for my normal user.

In /lib/udev/rules.d/50-udev-default.rules
  KERNEL=="vda",                                  SYMLINK+="sr1"
In /lib/udev/rules.d/91-permissions.rules
  KERNEL=="vda",                                  GROUP="cdrom"
(The developers of grep shall live long and prosper.) 

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

Have a nice day :)

Thomas

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

[Paolo Bonzini]

On 11/06/2011 09:14 PM, Thomas Schmitt wrote:
> Hi,
>
> i have finished CD and DVD tests with
>    drive file=/dev/sg2,if=virtio -cdrom /dvdbuffer/pseudo_drive
>
> There is substantial improvement towards if=scsi.
>
> Actually everything works like a charm now. :))

Cool.  So you might have unveiled some kernel bugs too (host crashes are 
never desirable!) but most of them were likely in the LSI emulation. 
I'll try some of the testcases on vmw_pvscsi to see if some are generic 
to SCSI.

Paolo

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

[Zhi Yong Wu]

On Thu, Nov 3, 2011 at 2:05 AM, Thomas Schmitt <scdbackup@gmx.net> wrote:
> Hi,
>
> i wrote:
>> > The sense code is listed in MMC as:
>> >    B 00 06 I/O PROCESS TERMINATED
>
> Paolo Bonzini wrote:
>> Is it good or bad? :)  I see it even in the very first command.
>
> It does not indicate success. MMC only has the meager info above.
>
> SPC-3 says in table 27 about sense key B:
>  "Bh : ABORTED COMMAND: Indicates that the device server aborted
>  the command. The application client may be able to recover by
>  trying the command again."
>
> It does not come from the real drive, i am very sure.
> So unless you find a particular reason in qemu, i doubt that repetition
> will help.
>
>
>> What do these give on the host?  Sounds like another LSI emulation bug.
>
> All is well with the drive on the host.
> This is my test machine, which checks build and function of xorriso
> with GNU/Linux, FreeBSD 8, and OpenSolaris. It also tested the
> freshly released libcdio-0.83 by Rocky Bernstein which uses
> on Linux ioctl(CDROM_SEND_PACKET) rather than ioctl(SG_IO).
>
> When i had trouble with vanishing udev links on Debian 6.0.2,
> i also tested with wodim. It worked as good as can be expected.
>
>
>> > The current release 1.1.6 will not recognize QEMU DVD-ROM because
>> > of its inconsistent Mode Page 2Ah with short Page Length (18 decimal).
>
>> The page length is indeed 18 for IDE and 20 for SCSI.  I made some changes
>> to that page recently, but left the 18 because I feared causing regression.
>> But if that is a bug, we can probably fix it in 1.0.
>
> This riddles me.
> In hw/scsi-disk.c:mode_sense_page() i see that the page 0x2A
> (now MODE_PAGE_CAPABILITIES) gets filled with 22 bytes, compliant
> to MMC-1. (Later MMCs have longer minimum sizes.)
> But libburn receives only 20 of them, because the Page Length
> is reported as 0x12 in the 10th byte of the reply:
>  MODE SENSE
>  5a 00 2a 00 00 00 00 00 1c 00
>  From drive: 28b
>  00 22 70 00 00 00 00 00 2a 12 00 00 71 60 29 00 02 c2 00 02
>  02 00 02 c2 00 00 00 00
> Nevertheless i see in hw/scsi-disk.c
>  p[1] = 0x14;
> So how is this altered to 0x12 in the further course of processing ?
>
> Further, the Mode Data Length is 0x22, announcing 34 + 2 = 36 overall
> bytes in the reply, which matches neither Page Length 0x12 nor 0x14,
> but would match Page Length 26 decimal = 0x1a.
>
> A real DVD-ROM drive ('HL-DT-ST' 'DVD-ROM GDR8162B') rather tells
>  MODE SENSE
>  5a 00 2a 00 00 00 00 00 1c 00
>  From drive: 28b
>  00 20 41 00 00 00 00 00 2a 18 3f 00 71 73 2b 23 21 13 01 00
>  01 00 0d c8 00 00 00 00
> so that libburn repeats the transaction with adjusted Allocation Length
>  MODE SENSE
>  5a 00 2a 00 00 00 00 00 22 00
>  From drive: 34b
>  00 20 41 00 00 00 00 00 2a 18 3f 00 71 73 2b 23 21 13 01 00
>  01 00 0d c8 00 00 00 00 00 00 00 01 00 00
>
> (Some Linux transports react badly if the Allocation Length surpasses
>  the actually available amount of bytes. So i adopted this two-step
>  strategy, which i learned from growisofs by Andy Polyakov.)
>
>
>> > Is it a known bug that 'QEMU DVD-ROM' is always empty if it stems
>> > from option -drive if=scsi ?
>> No, it is not a bug.  Remember this is an IDE DVD-ROM.  It is not
>> instantiated by -drive if=scsi: it is the same device that -cdrom crsates,
>
> You are the expert. So i do not contradict.
>
> But it behaves differently. The devices created by -cdrom do have
> a medium loaded. The 'QEMU DVD-ROM' from -drive if=scsi have no medium.
> (But the other drive 'CDDVDW SH-S223B' from -drive file=/dev/sg1,if=scsi
>  has a medium and replies the same as on the host system.)
>
> I just checked with the git clone.
> Readable are
>  -cdrom /dev/sr0
>  -cdrom /dvdbuffer/pseudo_drive  (a regular file)
> with dd and with xorriso (via guest SG_IO).
>
> No medium is found in
>  -drive file=/dev/sr0,if=scsi,media=cdrom
>  -drive file=/dvdbuffer/pseudo_drive,if=scsi,media=cdrom
> which report like the /dev/sg1 based 'QEMU DVD-ROM':
Yeah, i also met this same issue. The summary is very correct for me.

BTW: if the transfer mode is changed from DMA to PIO, it will fail.
/dev/sr0:
 multcount     =  0 (off)
 IO_support    =  1 (32-bit)
 readonly      =  0 (off)
 readahead     = 256 (on)
 HDIO_GETGEO failed: Inappropriate ioctl for device

 Model=QEMU DVD-ROM, FwRev=0.15.90, SerialNo=QM00003
 Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
 RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=DualPortCache, BuffSize=256kB, MaxMultSect=0
 CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
 IORDY=no, tPIO={min:300,w/IORDY:180}, tDMA={min:180,rec:180}
 PIO modes:  pio0 pio3 pio4
 DMA modes:  sdma0 sdma1 sdma2 mdma0 mdma1 *mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
 AdvancedPM=no
 Drive conforms to: Unspecified:  ATA/ATAPI-1,2,3,4

 * signifies the current active mode

If its transfer mode is changed:

/dev/sr0:
 setting xfermode to 8 (PIO flow control mode0)
 HDIO_DRIVE_CMD(setxfermode) failed: Invalid exchange

>
> No current profile (00 00 in bytes 6 and 7 of reply):
>  GET CONFIGURATION
>  46 00 00 00 00 00 00 00 14 00
>  From drive: 20b
>  00 00 00 10 00 00 00 00 00 00 03 08 00 10 00 00 00 08 00 00
>
> Error condition 2 3A 00 MEDIUM NOT PRESENT on
>  TEST UNIT READY
>  00 00 00 00 00 00
>  +++ sense data = F0 00 02 00 00 00 00 0A 00 00 00 00 3A 00 00 00 00 00
>  +++ key=2  asc=3Ah  ascq=00h   (     4 ms)
>
>
>> try inspecting /dev/disk and sysfs.  The ATAPI and SCSI code is
>> indeed very similar and will be even more similar in 1.0, but for now they
>> are distinct.
>
> They are not easy to distinguish since /dev/hdX passed the way.
>
>  $ ls /dev/disk
>  ata-QEMU_HARDDISK_QM00001        scsi-SATA_QEMU_HARDDISK_QM00001
>  ata-QEMU_HARDDISK_QM00001-part1  scsi-SATA_QEMU_HARDDISK_QM00001-part1
>  ata-QEMU_HARDDISK_QM00001-part2  scsi-SATA_QEMU_HARDDISK_QM00001-part2
>  ata-QEMU_HARDDISK_QM00001-part5  scsi-SATA_QEMU_HARDDISK_QM00001-part5
>
> With the "-part" suffixes, this does not look like a DVD+RW,
> which always only has one logical track.
>
>  $ ls -l /sys/bus/scsi/devices
>  total 0
>  lrwxrwxrwx 1 root root 0 Nov  2 18:30 0:0:0:0 -> ../../../devices/pci0000:00/0000:00:01.1/host0/target0:0:0/0:0:0:0
>  lrwxrwxrwx 1 root root 0 Nov  2 18:30 1:0:0:0 -> ../../../devices/pci0000:00/0000:00:01.1/host1/target1:0:0/1:0:0:0
>  lrwxrwxrwx 1 root root 0 Nov  2 18:35 2:0:0:0 -> ../../../devices/pci0000:00/0000:00:04.0/host2/target2:0:0/2:0:0:0
>  lrwxrwxrwx 1 root root 0 Nov  2 18:30 host0 -> ../../../devices/pci0000:00/0000:00:01.1/host0
>  lrwxrwxrwx 1 root root 0 Nov  2 18:30 host1 -> ../../../devices/pci0000:00/0000:00:01.1/host1
>  lrwxrwxrwx 1 root root 0 Nov  2 18:30 host2 -> ../../../devices/pci0000:00/0000:00:04.0/host2
>  lrwxrwxrwx 1 root root 0 Nov  2 18:30 target0:0:0 -> ../../../devices/pci0000:00/0000:00:01.1/host0/target0:0:0
>  lrwxrwxrwx 1 root root 0 Nov  2 18:30 target1:0:0 -> ../../../devices/pci0000:00/0000:00:01.1/host1/target1:0:0
>  lrwxrwxrwx 1 root root 0 Nov  2 18:35 target2:0:0 -> ../../../devices/pci0000:00/0000:00:04.0/host2/target2:0:0
>
>  $ cat /proc/scsi/sg/device_hdr /proc/scsi/sg/devices
>  host    chan    id      lun     type    opens   qdepth  busy    online
>  0       0       0       0       0       1       1       0       1
>  1       0       0       0       5       1       1       0       1
>  2       0       0       0       5       1       1       0       1
>  thomas@i386:~> cat /proc/scsi/sg/device_strs
>  ATA             QEMU HARDDISK           0.15
>  QEMU            QEMU DVD-ROM            0.15
>  TSSTcorp        CDDVDW SH-S223B         SB02
>
> This is inconclusive, as it lists the hard disk too.
>
> Whatever the reason, there is a problem with -drive if=scsi,medium=cdrom.
>
>
> Have a nice day :)
>
> Thomas
>
>
>



-- 
Regards,

Zhi Yong Wu

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

[Thomas Schmitt]

Hi,

> >    drive file=/dev/sg2,if=virtio -cdrom /dvdbuffer/pseudo_drive
> >  Actually everything works like a charm now. :))

> Cool.  So you might have unveiled some kernel bugs too (host crashes are
> never desirable!)

The USB drive is back at the test machine.
I'm running the planned BD-RE tests on the host system to ensure that
they work properly without qemu inbetween.

Next i will try with if=virtio.


Some questions:
-----------------------------------------------------------------------

In a thread on linux-hotplug, /dev/sg* is declared to be deprecated
in favor of /dev/bsg/* and /dev/sr*.
Will this become a problem ?

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

I did not succeed with googling for a way to get a block device
running on top of file=/dev/sg*,if=virtio.
Is this possible at all ? If so, can you give me instructions ?
(It would be the cream cap on the cake.)

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

The word "passthrough" does not show up in the context of drive
emulation in any documentation inside the git clone.
I only see statements about:  "passthrough" security model.
The word "virtio" is mentioned more often, but without much explanation
of -drive use cases and pitfalls. (Only docs/qdev-device-use.txt
has some more detailed information.)

Is there an external documentation emerging ?
I would like to read it and contribute my experiences.

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

Have a nice day :)

Thomas

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

[Paolo Bonzini]

On 11/07/2011 11:04 AM, Thomas Schmitt wrote:
> In a thread on linux-hotplug, /dev/sg* is declared to be deprecated
> in favor of/dev/bsg/* and /dev/sr*.
> Will this become a problem ?

I think /dev/bsg is backwards-compatible more or less, but it would help
if it had decent documentation in the kernel tree.

> I did not succeed with googling for a way to get a block device
> running on top of file=/dev/sg*,if=virtio.

No, that's not possible with /dev/sg.  But I think this helps:

   -drive file=/dev/sr0,if=none,id=scsicd
   -device virtio-blk,drive=scsicd,logical_block_size=2048,physical_block_size=2048

At least here, dd works with this command line.  This probably will
be fixed in QEMU 1.1 (i.e. the release after the next one).

> The word "passthrough" does not show up in the context of drive
> emulation in any documentation inside the git clone.
> I only see statements about:  "passthrough" security model.
> The word "virtio" is mentioned more often, but without much explanation
> of -drive use cases and pitfalls. (Only docs/qdev-device-use.txt
> has some more detailed information.)

Yes, docs/qdev-device-use.txt helps.  "qemu -device virtio-blk,?" too.

> Is there an external documentation emerging ?
> I would like to read it and contribute my experiences.

Hopefully, everything would just work. :)

You can work on wiki.qemu.org in the meanwhile.

Paolo

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

[Zhi Yong Wu]

On Mon, Nov 7, 2011 at 7:13 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 11/07/2011 11:04 AM, Thomas Schmitt wrote:
>> In a thread on linux-hotplug, /dev/sg* is declared to be deprecated
>> in favor of/dev/bsg/* and /dev/sr*.
>> Will this become a problem ?
>
> I think /dev/bsg is backwards-compatible more or less, but it would help
> if it had decent documentation in the kernel tree.
>
>> I did not succeed with googling for a way to get a block device
>> running on top of file=/dev/sg*,if=virtio.
>
> No, that's not possible with /dev/sg.  But I think this helps:
>
>   -drive file=/dev/sr0,if=none,id=scsicd
>   -device virtio-blk,drive=scsicd,logical_block_size=2048,physical_block_size=2048
It didn't work for me
I started up one os=rh6.1 guest with above options.

On guest:
[root@localhost ~]# mount /dev/sr0 /tmp/1
mount: you must specify the filesystem type
[root@localhost ~]#

>
> At least here, dd works with this command line.  This probably will
> be fixed in QEMU 1.1 (i.e. the release after the next one).
>
>> The word "passthrough" does not show up in the context of drive
>> emulation in any documentation inside the git clone.
>> I only see statements about:  "passthrough" security model.
>> The word "virtio" is mentioned more often, but without much explanation
>> of -drive use cases and pitfalls. (Only docs/qdev-device-use.txt
>> has some more detailed information.)
>
> Yes, docs/qdev-device-use.txt helps.  "qemu -device virtio-blk,?" too.
>
>> Is there an external documentation emerging ?
>> I would like to read it and contribute my experiences.
>
> Hopefully, everything would just work. :)
>
> You can work on wiki.qemu.org in the meanwhile.
>
> Paolo
>
>



-- 
Regards,

Zhi Yong Wu

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

[Paolo Bonzini]

On 11/07/2011 12:24 PM, Zhi Yong Wu wrote:
> It didn't work for me
> I started up one os=rh6.1 guest with above options.
>
> On guest:
> [root@localhost ~]# mount /dev/sr0 /tmp/1
> mount: you must specify the filesystem type
> [root@localhost ~]#

You asked for a virtio disk, not a SCSI disk.  The CD-ROM will be under 
/dev/vdX.  mount works here.

Paolo

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

[Zhi Yong Wu]

On Mon, Nov 7, 2011 at 7:29 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 11/07/2011 12:24 PM, Zhi Yong Wu wrote:
>>
>> It didn't work for me
>> I started up one os=rh6.1 guest with above options.
>>
>> On guest:
>> [root@localhost ~]# mount /dev/sr0 /tmp/1
>> mount: you must specify the filesystem type
>> [root@localhost ~]#
>
> You asked for a virtio disk, not a SCSI disk.  The CD-ROM will be under
Sorry, made one mistake. Yeah, It can work.
This id=scsicd maning is a bit confusing...

Moreover, When the option -device lsi -device scsi-cd,... is
specified, it can also work.

> /dev/vdX.  mount works here.

>
> Paolo
>
>



-- 
Regards,

Zhi Yong Wu