Features/qtest driver framework: Difference between revisions

From QEMU
No edit summary
No edit summary
Line 2: Line 2:


For example, the framework could provide:
For example, the framework could provide:
# an interface for SD-HCI devices (abstract class ''QSDHCI'')
# an interface for SD-HCI (SD Host Controller Interface) devices (abstract class ''QSDHCI'')
# a driver for a PCI SD Host Controller Interface device (a subclass of QSDHCI, for example QSDHCI_PCI)
# a driver for PCI SD-HCI devices (a subclass of QSDHCI, for example QSDHCI_PCI)
# a description of how QEMU's "sdhci-pci" device maps to QSDHCI_PCI
# a description of how QEMU's "sdhci-pci" device maps to QSDHCI_PCI (for simplicity this can be part of QSDHCI_PCI)
# an interface for a PCI bus (abstract class ''QPCIBus'')
# an interface for a PCI bus (abstract class ''QPCIBus'')
# a driver for the PCI bus in an x86 PC machine (a subclass of QPCIBus, for example QPCIBusPC)
# a driver for the PCI bus in an x86 PC machine (a subclass of QPCIBus, for example QPCIBusPC)

Revision as of 11:44, 16 March 2018

Through a driver framework, libqos can expose a description of QEMU's supported machine types and a set of drivers; unit tests can request a driver, and the framework takes care of starting QEMU with options that provide that driver.

For example, the framework could provide:

  1. an interface for SD-HCI (SD Host Controller Interface) devices (abstract class QSDHCI)
  2. a driver for PCI SD-HCI devices (a subclass of QSDHCI, for example QSDHCI_PCI)
  3. a description of how QEMU's "sdhci-pci" device maps to QSDHCI_PCI (for simplicity this can be part of QSDHCI_PCI)
  4. an interface for a PCI bus (abstract class QPCIBus)
  5. a driver for the PCI bus in an x86 PC machine (a subclass of QPCIBus, for example QPCIBusPC)
  6. a description of QEMU's "pc" machine (a subclass of QOSMachine) and its embedded devices (in this case a QPCIBusPC)

(Right now libqos provides items 4 and 5 only).

You can construct a graph where the nodes are interfaces, drivers and unit tests, connected by relations such as "X produces Y" or "X consumes Y":

 (driver)           (driver)           (interface)        (interface)        (driver)
     pc  ────────→ i440FX-host ───────→ QPCIBusPC  ───────→ QPCIBus ───────→ QSDHCIPCI
          produces             produces              is-a           consumes     │ produces
                                                                                 ↓
                                                                            (interface)
                                                                              QSDHCI
                                                                                 │ consumes
                                                                                 ↓
                                                                             register-test

(The above is just a single path in the huge graph for the "x86_64" QEMU target architecture!). For example, a unit test for the SD-HCI device (let's call it "registers-test") would add itself to the graph like this:

 qos_add_test("register-test", "sdhci");
                    │             ╰────── Interface consumed by the test
                    ╰──────────────────── Test name

After the graph is build, tests can be discovered by walking the graph: each test to run corresponds to a path from the root of the graphs to a unit test. The above path could represent a test like "/x86_64/pc/i440FX-host/pcibus-pci/sdhci-pci/sdhci/registers-test":

  /x86_64-softmmu/pc/i440FX-host/pcibus-pc/sdhci-pci/sdhci/registers-test
        │         │       │          │         │        │       ╰──── Test name
        │         │       │          │         │        ╰──────────── Driver or interface provided by "sdhci-pci"
        │         │       │          │         ╰───────────────────── Device on the PCI bus
        │         │       │          ╰─────────────────────────────── Driver or interface provided by "i440FX-host"
        │         │       ╰────────────────────────────────────────── Device embedded by "pc"
        │         ╰────────────────────────────────────────────────── QEMU machine
        ╰──────────────────────────────────────────────────────────── Target architecture

At run-time, a lot of steps are hidden in the framework, and are realized by walking the path on the graph:

  • QOSMachine walks the path to the device under test
    • the machine itself adds "-M pc" to the command line
    • QPCIBusPC need not add anything to the command line because the device is embedded
    • QSDHCI_PCI adds "-device sdhci-pci" to the command line
  • QOSMachine starts QEMU
  • QOSMachine finally executes the code for the unit test
    • The test asks QSDHCI_PCI to start the device
      • QSDHCI_PCI sets up the PCI device using the methods of QPCIBus
    • The test runs and tests the SDHCI device