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

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

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