= qdev Status =

qdev is a QEMU-internal API for device configuration and creation. It's the machinery that makes -device and device_add / device_del possible. Devices are being converted to qdev, and qdev evolves along with that. This page tracks how far we got, and what's still left to do.

=== Host/guest split ===

* Drives done
** Host side: -drive if=none,id=<name>,<parameters>
** Guest side: -device virtio-blk-pci,drive=<name>

* Character devices done
** Host side: -chardev pty,id=<name>
** Guest side: -device isa-serial,chr=<name>
** A few small issues remain, e.g. -device isa-serial still requires -serial none to work. See "default optional devices" below.

* NICs are still in RFC stage. Gerd and Mark posted patches for discussion. Mark proposed -netdev, similar in spirit to -chardev.

=== PC driver conversion status ===

* PIC, APIC, CPUs, memory not converted
* i440FX/PIIX3 done (host bridge, ISA bridge, USB, IDE) except for ACPI (PIIX3 function 3)

* ISA FDC, PS/2 keyboard & mouse, RTC, serial, parallel done
* Working on nicer defaults for -device serial and parallel

* VGA done (all variants, ISA & PCI), except for ROMs (see "option ROMs" below)

* NICs partly converted, missing are host/guest split (see above) and boot ROMs (see "option ROMs" below)

* Audio done, except for a few rarely used ISA devices

* Virtio done, except virtio-console still needs chardev hooked up (Amit's working on it as part of vmchannel)

* SCSI done

* USB HID (tablet, mouse, keyboard), storage, hub done.
* USB serial, net, host (pass-through) serial partly converted.

* IDE disks done, but see "default optional devices" below

* Watchdogs done

* Bluetooth not converted

* Option ROMs not done, but getting very close

=== Default optional devices ===

QEMU creates a bunch of optional devices (NIC, CD-ROM, VGA, ...). Some of them can be suppressed, some not. Default devices get in the way when you work with -device & friends. For instance, ide1/master is untouchable, because QEMU insists on putting a CD-ROM there. Being discussed upstream.

=== Hot plug ===

device_add / device_del are on par with -device: Any device you can create with -device you can hot-plug with device_add / device_del. As long as it's hot-pluggable, of course.

drive_add is on par with -drive. May still need drive_del.

Still need equivalents to -chardev and future -netdev (what drive_add is to -drive).

=== Resources ===

Gerd's [http://repo.or.cz/w/qemu/kraxel.git git tree]

Bugs

2009-07-09T21:10:30Z

MarkusArmbruster: Fix markup

=Bugs=

You can submit bug reports either through the sourceforge [http://sourceforge.net/tracker/?atid=893831&group_id=180599&func=browse bug tracker] or directly to the [mailto:kvm@vger.kernel.org mailing list] (no need to subscribe). Bugs submitted through the bug tracker show up on the list as well.

== Submitting a bug report ==

When submitting a bug report, make sure to provide the following information:

* what cpu model (examples: Intel Core Duo, Intel Core 2 Duo, AMD Opteron 2210). See /proc/cpuinfo if you're not sure.
* what kvm version you are using. If you're using git directly, provide the output of 'git describe'.
* the host kernel version
* what host kernel arch you are using (i386 or x86_64)
* what guest you are using, including OS type (Linux, Windows, Solaris, etc.), bitness (32 or 64), kernel version
* the qemu command line you are using to start the guest
* whether the problem goes away if using the <code>-no-kvm-irqchip</code> or <code>-no-kvm-pit</code> switch.
* whether the problem also appears with the <code>-no-kvm</code> switch.

Please use the latest release version of kvm at the time you submit the bug. Even if you use kvm from a distribution (Ubuntu starting from Feisty or Fedora starting from 7), it is important to use the latest sources.

In case qemu-kvm exits with SIGSEGV (Segmentation fault) or SIGBUS (Bus error), please make sure ulimit is configured so that a core file can be generated (ulimit -a to report, ulimit -c unlimited to allow unlimited size core files). Then get a backtrace of the error with

(gdb) info threads

And for every thread present do:

(gdb) thread n

(gdb) bt

Attach the output to the bug report.

== Getting a serial console from the guest ==

If a guest crashes on boot, it is sometimes useful to have its console output. This can be done using
qemu's -serial option to emulate a serial port:
qemu-system-x86_64 -serial file:serial.log

Depending on the guest OS you will need to do some additional changes to instruct it to use the serial port as a console as shown below :

=== Linux ===

Change the guest kernel's command line (in the GRUB or LILO menu) to include the string
console=ttyS0,115200

If after a crash, there is still no output in the serial.log file and the guest kernel was configured touse a serial console; chances are that the crash was too early in the process to have the console initialized and then the following kernel command line should be used additionally (only to be used as a last resort as it interacts badly with the console boot parameter)
earlyprintk=serial,ttyS0,115200

=== OpenSolaris ===

Change the guest kernel's entry in the GRUB menu to include the string
-B console=ttya

if there is already a -B option just add the console parameter to it after a comma "," and beware that since this will redirect the console to the file you'll need to tail the serial.log file to see it boot asthere will be no output in the SDL console and you won't be able to interact with it through the keyboard.