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
next 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).