Testing/CCWTestDevice: Difference between revisions
(Created page with "= CCW Test Device = We want to provide a device in QEMU that can be used to test various kind of channel programs for s390x machines. This device should be distinct from curr...") |
(Let's use 0xffff for the cu type.) |
||
| Line 5: | Line 5: | ||
== General approach == | == General approach == | ||
Provide a device derived from TYPE_CCW_DEVICE that can be instantiated via the normal -device mechanism. It needs a control unit type especially reserved for testing. A ccw interpretation callback can be used to process different kinds of ccws. | Provide a device derived from TYPE_CCW_DEVICE that can be instantiated via the normal -device mechanism. It needs a control unit type especially reserved for testing. As only numbers are used for real control unit types, 0xffff looks like a decent choice for that. A ccw interpretation callback can be used to process different kinds of ccws. | ||
From the guest side, this looks like a normal ccw device. Testing might be done via a custom Linux kernel driver, the kvm-test infrastructure or qtest. | From the guest side, this looks like a normal ccw device. Testing might be done via a custom Linux kernel driver, the kvm-test infrastructure or qtest. | ||
| Line 15: | Line 15: | ||
== To Do == | == To Do == | ||
* Factor out the existing test, making it extensible. | * Factor out the existing test, making it extensible. | ||
* Evaluate various options for the guest side. | * Evaluate various options for the guest side. | ||
Latest revision as of 08:46, 18 September 2017
CCW Test Device
We want to provide a device in QEMU that can be used to test various kind of channel programs for s390x machines. This device should be distinct from currently exiting emulated devices (like virtio-ccw or 3270). This can be used to test features mandated by the architecture that are not yet implemented for any device that QEMU supports, as well as for exercising seldom-used error paths.
General approach
Provide a device derived from TYPE_CCW_DEVICE that can be instantiated via the normal -device mechanism. It needs a control unit type especially reserved for testing. As only numbers are used for real control unit types, 0xffff looks like a decent choice for that. A ccw interpretation callback can be used to process different kinds of ccws.
From the guest side, this looks like a normal ccw device. Testing might be done via a custom Linux kernel driver, the kvm-test infrastructure or qtest.
Example
A device for testing data addressing has been posted at [1].
To Do
- Factor out the existing test, making it extensible.
- Evaluate various options for the guest side.
Things to test
- data handling (as in the example)
- channel program chains (including things like TIC)
- error handling (various unit checks etc.)
- channel program fuzzing
- suspending/resuming a channel program