[Qemu-devel] Summary of CD, DVD, BD passthrough tests with -drive if=none -device virtio-blk

[Qemu-devel] Summary of CD, DVD, BD passthrough tests with -drive if=none -device virtio-blk

[Thomas Schmitt]

Hi,

the test results on CD-RW, DVD-RW, DVD+RW, BD-RE are flawless with
Paolo Bonzini's most recent proposal
 -drive file=/dev/sr2,if=none,id=scsicd
 -device virtio-blk,drive=scsicd,logical_block_size=2048,physical_block_size=2048

libburn works fine via SG_IO. dd and other unaware readers work fine.
Chances are good that growisofs, cdrecord, and wodim will work fine, too.

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

But i want to strongly suggest to open the host drive with option O_EXCL,
which has a fewly documented meaning as advisory locking mechanism
(at least with /dev/sg and /dev/sr).

It is used to indicate that the device is mounted, burn programs
use it to indicate that the drive is occupied. Both meanings are
not 100 % compatible, but the best we can get to avoid burn
burn coasters or problems with vanishing data on mounted read-only
filesystems.

Symptoms:

xorriso on the host should not list /dev/sr2, but does it.
It would be able to interfere with the guest xorriso.
Not good.  Would spoil CD and DVD- burn runs.

My spy printf say in the qemu start terminal:

  block/raw-posix.c: cdrom_open("/dev/sr2", 0)
  block/raw-posix.c: raw_open_common("/dev/sr2", 1800)
  block/raw-posix.c: cdrom_open("/dev/sr2", 2)
  block/raw-posix.c: raw_open_common("/dev/sr2", 1802)

/usr/include/bits/fcntl.h has
  #define O_EXCL             0200

(What flag is 0x800, btw ?)

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

qemu start command (still the git clone of 2 November 2011) :

  .../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/sr2,if=none,id=scsicd \
    -device virtio-blk,drive=scsicd,logical_block_size=2048,physical_block_size=2048 \
    -cdrom /dvdbuffer/pseudo_drive

Host system is Debian GNU/Linux 6.0.2 amd64.

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

Preparations on guest system Debian GNU/Linux 6.0.3 i386

  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"

  This yields
    lrwxrwxrwx 1 root root       3 Nov  8 11:19 /dev/sr1 -> vda
    brw-rw---- 1 root cdrom 254, 0 Nov  8 11:19 /dev/vda
  which allows me to run the tests as normal user in group cdrom.

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

During the tests i wrote a description how to set them up and to perform
them.

It turned out that about 25 lines concern qemu, 20 concern the Debian guest,
and 400 lines concern xorriso and its expected behavior.
So it makes more sense to create a qemu related page in the wiki of
the libburnia project, rather than to submit it to qemu.

I will publish that text as soon as a GNU xorriso development tarball
is available which works on qemu without the need for a micro hack
in libbur/sg-linux.c
    - static int linux_sg_accept_any_type = 0;
    + static int linux_sg_accept_any_type = 1;
This hacklet is not without dangers. I actually need to tell CD drives
from other device types.

I will post its URL on this list when it is available.

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

Have a nice day :)

Re: [Qemu-devel] Summary of CD, DVD, BD passthrough tests with -drive if=none -device virtio-blk

[Thomas Schmitt]

Hi,

i am now testing a hack that adds O_EXCL to the call of qemu_open()
in block/raw-posix.c. Just as proof-of-concept.

This is Linux-host-specific, of course.

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

As first i learned to distinguish between octal and hex. :))
So my question "(What flag is 0x800, btw ?)" is obsolete.

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

During the O_EXCL test i was bitten by a little pitfall of
the proposed virtual device setup. It happens with the well
tested version of my git clone, too.

If there is no medium inside, then qemu start-up fails with

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

If there is a blank DVD-RW medium loaded. i get:

  qemu-system-x86_64: -drive file=/dev/sr2,if=none,id=scsicd: could not open disk image /dev/sr2: Input/output error

Would it be possible to make qemu more tolerant here ?

(For a better error message, one would would have to inquire the medium.
 READ DISC INFORMATION, Disc Status 00b "Empty" means blank medium,
 MMC-1 table 131, MMC-3 table 163.
 No medium would be indicated by sense code 2 3A xx MEDIUM NOT PRESENT.)

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

I am worrying now about my happy ejecting and changing of media, while
qemu has open the same device descriptor all the time.

Is this sane for the host system resp. for qemu ?
If above initialization of 'virtio-blk-pci' is needed, then wouldn't
it be needed after each media change ?

There are no visible bad effects, though.

-----------------------------------------------------------------------
For O_EXCL tests:

The start terminal now says

  block/raw-posix.c: raw_open_common("/dev/sr2", 0x1800)
  block/raw-posix.c: raw_open_common("/dev/sr2", 0x1802)
  block/raw-posix.c: /dev/sr O_EXCL test : s->open_flags is now 0x1882

I added O_EXCL only to the open call with O_RDWR, because this combination
is known to work on older Linux kernels, where O_RDONLY sometimes ignores
the extra meaning of O_EXCL. (Which is not described in man 2 open.)

In any case one has to avoid to use O_EXCLi on that device, while there
is still another own open O_EXCL file descriptor for the device.
Else self-denial.

One could re-try without O_EXCL after a failure. That would still be
more protection than there is now. libburn and wodim wait a second and
retry with O_EXCL, because there is sometimes a delay with unlocking.

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

On the host system, xorriso now reports as i wish

  libburn : SORRY : Cannot open busy device '/dev/sr2' : Device or resource busy
  0  -dev '/dev/sr0' rwrw-- :  'TSSTcorp' 'DVD-ROM SH-D162C' 
  1  -dev '/dev/sr1' rwrw-- :  'TSSTcorp' 'CDDVDW SH-S223B' 

 
I made a quick tour through my emerging qemu test wiki page with DVD-RW.
It all looks as good as before.


If there is a further opening call with O_RDWR, then it does not happen
with my setup, my use cases, and my hack in raw_open_common():

  + if (strncmp(filename, "/dev/sr", 7) == 0 && (s->open_flags & O_RDWR)) {
  +     s->open_flags |= O_EXCL;
  +     printf("block/raw-posix.c: /dev/sr O_EXCL test : s->open_flags is now 0x%x\n", s->open_flags);
  + }
  +
    s->fd = -1;
    fd = qemu_open(filename, s->open_flags, 0644);

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


Have a nice day :)

Thomas