Features/virtio-refactoring: Difference between revisions

From QEMU
Line 10: Line 10:
== Details ==
== Details ==


Actually QEMU have a lot of virtio-device, which are not QOM compliant, and can be used through two transports:
Actually QEMU has a lot of virtio devices, which are not QOM compliant; they can be used with two different transports:
* PCI: with eg: -device virtio-blk-pci.
* PCI: with eg: -device virtio-blk-pci.
* S390: with eg: -device virtio-blk-s390.
* S390: with eg: -device virtio-blk-s390.


The new implementation should be the following:
The new implementation is as follows:


* A new bus is introduced: virtio-bus which is an abstract bus.
* A new bus is introduced: virtio-bus which is an abstract bus.
* For each transport: introduce a specific implementation of virtio-bus. (eg: virtio-pci-bus for virtio-pci).
* For each transport a specific implementation of virtio-bus is created. (eg: virtio-pci-bus for virtio-pci).
* Each transport device has a virtio-bus.
* Each virtio transport is built with a virtio-bus that the virtio devices connect to.
* VirtioDevice become a device which is abstract and must be connected on a virtio-bus.
* VirtIODevice becomes a device which is abstract and must be connected on a virtio-bus.
* Each virtio device are created (eg: virtio-blk) extends VirtioDevice and then connects on a virtio-bus.
* Each virtio device are created (eg: virtio-blk) extends VirtioDevice and then connects on a virtio-bus.



Revision as of 20:20, 15 January 2013

Summary

The Virtio devices need to be refactored to use the QOM implementation.

Owner

Details

Actually QEMU has a lot of virtio devices, which are not QOM compliant; they can be used with two different transports:

  • PCI: with eg: -device virtio-blk-pci.
  • S390: with eg: -device virtio-blk-s390.

The new implementation is as follows:

  • A new bus is introduced: virtio-bus which is an abstract bus.
  • For each transport a specific implementation of virtio-bus is created. (eg: virtio-pci-bus for virtio-pci).
  • Each virtio transport is built with a virtio-bus that the virtio devices connect to.
  • VirtIODevice becomes a device which is abstract and must be connected on a virtio-bus.
  • Each virtio device are created (eg: virtio-blk) extends VirtioDevice and then connects on a virtio-bus.

As we discussed, we must keep the backward compatibility. So the re-factored device must have the same properties and the same behavior. We should have only one way to create the device, so the transport/virtio-bus/virtio-device layout is only internal to QEMU for S390 and PCI device.

Status

Item Status Reviewed Tested
Introduce virtio-bus Done yes yes
Create virtio-device Done yes
Introduce virtio-pci-bus Done yes
Refactor virtio-pci Done yes
Introduce virtio-s390-bus Done yes
Refactor virtio-s390-device Done yes
Refactor virtio-blk Done
Refactor virtio-net Done
Refactor virtio-scsi Done
Refactor virtio-balloon Done
Refactor virtio-rng Done
Refactor virtio-serial Done
Refactor virtio-9p Done yes
Clean-up Done

Git

The re-factoring is in three parts, to have smaller patch-set:

  • The first part is introduction of virtio-bus (including virtio-pci-bus and virtio-s390-bus), creation of virtio-device, re-factoring of virtio-pci and virtio-s390-device.

git://git.greensocs.com/qemu_virtio.git virtio_v3_part1

  • The second part is the re-factoring of all virtio backend.

git://git.greensocs.com/qemu_virtio.git virtio_v3_part2

  • The third part is a clean-up patch-set.

git://git.greensocs.com/qemu_virtio.git virtio_v3_part3

For testing just pull the third part, no need to pull the two firsts.