[Libcdio-devel] About real CD drives accessible by qemu guests

[Thomas Schmitt]

Hi,

in the last weeks i explored the opportunities of giving qemu guest
systems access to real CD drives of the host system. Both, guest and
host were GNU/Linux systems (host: Debian 6.0.2, guest: Debian 6.0.3).

Three setups turned out to be usable for burning CD, DVD, and BD
via MMC commands. This were not only write commands but also status
inquiries and data reading commands.
So there is hope that libcdio will be able to operate on such drives
via MMC and via host system facilities which are based on MMC.


The drive shows up as SCSI device or as virtio device.
It is important to also give an emulated ATAPI drive by -cdrom or
else strange things might happen to the emulation of the real drive.

The setup examples below expose host drive /dev/sr0 to the guest.

On start of the guest there should be a readable medium with
maximum size in the real drive. At least the Debian 6.0.2 host will
not learn about any size changes of the medium after the guest was
started. So the host block device driver will always assume the size
that was valid at guest start.
qemu and the guest partly rely on that host block device driver.


I modified a vanilla qemu start command

  qemu \
    -enable-kvm -nographic -m 512 \
    -net nic,model=ne2k_pci -net user,hostfwd=tcp::5558-:22 \
    -hda /dvdbuffer/i386-install.qemu \
    -cdrom /dvdbuffer/pseudo_drive

by -device and -drive definitions which were proposed by Paolo Bonzini.
(The base command was mainly learned from GNU/Hurd qemu page.)

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

Setups 1 works with qemu-1.0-rc3 which will become qemu-1.0 in
a couple of days:

    -device lsi,id=scsi \
    -drive file=/dev/sr0,id=cd,if=none,format=raw \
    -device scsi-block,drive=cd,bus=scsi.0 \

The exposed drive has a few quirks. E.g. some READ DISC STRUCTURE inquiries
get stuck until the timeout expires.
The guest Linux logged two call stacks (but no Ooops) and needed about
three minutes to produce a /dev/sr1 device file. Timeouts, i guess.

I understand that the emulated SCSI controller is old and conventional
but not totally bug-free.

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

Setup 2 works with qemu-0.15.1 and qemu-1.0-rc3:

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

This works perfectly with MMC commands. But the guest Linux did not
show a /dev/sr device file of group "cdrom". It rather was /dev/vda
belonging to group "disk".
I accompanied it by a link /dev/sr1 and changed its group membership
by help of udev. See
  http://libburnia-project.org/wiki/QemuXorriso
for details.

I understand that /dev/vda stems from Linux being aware of virtio
device emulation. Probably older operating systems will not recognize
this emulated PCI controller.

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

Setup 3 works with a git development branch of Paolo Bonzini:

    -device vmw_pvscsi,id=scsi \
    -drive file=/dev/sr0,id=cd,if=none,format=raw \
    -device scsi-block,drive=cd,bus=scsi.0 \

It works with MMC as good as above virtio setup, and it has the advantage
to let Linux show a /dev/sr1 of group "cdrom" out of the box.

I understand this is a VMware-style emulated PCI controller which
might need special awareness of the guest operating system.

The git clone was obtained in several steps. I am sure one can
straighten this:
  git clone git://git.qemu.org/qemu.git
a few days later:
  git remote add -f pbonzini git://github.com/bonzini/qemu.git
  git checkout pbonzini/scsi-mmc
  ./configure --target-list=x86_64-softmmu && make
and another few days later:
  git fetch pbonzini
  git checkout pbonzini/scsi-mmc
  ./configure --target-list=x86_64-softmmu && make

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

Regrettably, none of theses setups produced a device in a GNU/Hurd
guest, which is my motivation for exploring qemu SCSI passthrough.
I will have to learn how to update my Hurd to the newest state and
then cry for help at bug-hurd list.

Hurd has no passthrough command for SCSI and ATAPI yet.
My long term goal is to drill a hole to the Linux 2.0 drivers which i
could spot in gnumach.


Have a nice day :)

Thomas