qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: [Qemu-devel] qdev status report
Date: Wed, 02 Sep 2009 11:10:41 +0200	[thread overview]
Message-ID: <4A9E3691.5070608@redhat.com> (raw)

   Hi,

This is a summary of where we stand in terms of converting drivers to
qdev (with pc being the main focus).


qdev status report
==================

There are basically three different states a driver can be in:

not converted
   Obvious, right?

partly converted
   The device will appear in the qdev tree.  It will be visible in the
   'info qtree' monitor command (when properly connected all the way up
   to the main system bus).  The setup still goes the old, hard-coded
   code paths for setting up device parameters though.

fully converted
   The device is setup uses qdev properties for all device parameters.
   Which means you can create fully functional instances of the device
   using the -device command line switch.


Note that not all qemu configuration is in the qdev tree.  We have
host side state and guest side state.  qdev only handles the guest
side state, i.e. the devices seen by the guest.  The host side state
is not covered by qdev.  Having a clear split between host and guest
state is required though.  Linking host state to a guest device is
done using properties.


host/guest split: drives
------------------------

Works.
Host side:   -drive if=none,id=<name>,<parameters>
Guest side:  -device virtio-blk-pci,drive=<name>


host/guest split: chardevs
--------------------------

I'm working on it.  Plan:
Host side:   -chardev pty,id=<name>
Guest side:  -device serial,chr=<name>

Note: Creating named+unconnected chardevs is also useful for
slirp forwarding.


host/guest split: nics
----------------------

Not investigated yet in detail.

The current way of having a NICInfo pointer as DeviceState->nd is a
big hack.  The info in NICInfo should be attributes instead, and in
fact some already covered by qdev.  Big question is how we'll link the
guest nic to the host side.  Property with a vlan number?  IIRC there
are plans to replace vlans with something else, what is the state
there?


pc driver conversion status
---------------------------

core stuff: pic,apic,cpus,memory -- not converted

isa: floppy -- partly converted
isa: ps/2 -- partly converted
isa: all others: not converted

pci: hostbridge (i440fx) -- partly converted
pci: all vga -- partly converted
     -> vgabios is not handled.

pci: nics -- partly converted
     -> see above: nic guest/host split.
     -> also: bootrom is not handled.

pci sound -- fully converted
virtio-blk -- fully converted
virtio-balloon -- fully converted

virtio-console -- party converted
     -> depends on chardev work

scsi -- fully converted
     -> not merged yet, patches went to the list a few days ago.

usb uhci -- fully converted
usb ohci -- pci version is fully converted.
usb hid -- fully converted
usb msd -- fully converted
usb others -- partly converted
     -> all usb not merged yet, patches went to the list a few days ago.
     -> some usb devs depend on chardev work.

ide -- not converted
     -> I'm working on it.

watchdogs -- fully converted

serial,parallel -- not converted
     -> depends on chardev work

bluetooth -- not converted

cheers,
   Gerd

             reply	other threads:[~2009-09-02  9:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-02  9:10 Gerd Hoffmann [this message]
2009-09-02 10:23 ` [Qemu-devel] qdev status report malc
2009-09-02 10:57   ` Gerd Hoffmann
2009-09-02 11:11     ` malc
2009-09-02 15:02 ` Blue Swirl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A9E3691.5070608@redhat.com \
    --to=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).