Features/virtio-refactoring: Difference between revisions
FredKonrad (talk | contribs) |
FredKonrad (talk | contribs) |
||
| Line 10: | Line 10: | ||
== Details == | == Details == | ||
Actually QEMU | 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 | 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 | * For each transport a specific implementation of virtio-bus is created. (eg: virtio-pci-bus for virtio-pci). | ||
* Each transport | * 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. | * 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
- Name: Fred Konrad
- Email: fred.konrad@greensocs.com
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.