Re: [Qemu-devel] qdev status report

[Blue Swirl]

On Wed, Sep 2, 2009 at 12:10 PM, Gerd Hoffmann<address@hidden> wrote:
>  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

Sparc32 driver conversion status
---------------------------
all devices: fully converted

Sparc64 driver conversion status
---------------------------
native devices: fully converted
pc devices: see above