Re: [Qemu-devel] [RFC PATCH v2 1/3] s390x/ccs: add ccw-testdev emulated device

[Halil Pasic <pasic@linux.vnet.ibm.com>]

On 11/23/2017 09:20 AM, Dong Jia Shi wrote:
> * Halil Pasic <pasic@linux.vnet.ibm.com> [2017-11-08 17:54:20 +0100]:
> 
> Hi Halil,
> 
>> Add a fake device meant for testing the correctness of our css emulation.
>>
>> What we currently have is writing a Fibonacci sequence of uint32_t to the
>> device via ccw write. The write is going to fail if it ain't a Fibonacci
>> and indicate a device exception in scsw together with the proper residual
>> count. With this we can do basic verification of data integrity.
>>
>> Of course lot's of invalid inputs (besides basic data processing) can be
>> tested with that as well.
>>
>> We also have a no-op mode where the device just tells all-good! This
>> could be useful for fuzzing.
>>
>> Usage:
>> 1) fire up a qemu with something like -device ccw-testdev,devno=fe.0.0001
>>    on the command line
>> 2) exercise the device from the guest
>>
>> Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com>
>> ---
>>
>> Introduction
>> ------------
>>
>> While discussing v1 we (more or less) decided a test device for ccw is a
>> good idea. This is an RFC because there are some unresolved technical
>> questions I would like to discuss.
>>
> Regarding to test coverage, this mainly covers the cds_read. 

This series has only a linux module with some texts and is more
of a PoC than the way it should be done. I think I wrote somewhere
about this.

The ccw-testdev being mainly about cds_read is not correct. See
the TIC must have zero count test in patch 3. The cds things only
become relevant if data matters for the test. The ccw-testdev is
about making it possible to check how does the channel subsystem respond
to certain stimuli without actually having to care about a real device.

> What we
> want would be surely more than this. So to extend the coverage, we need
> to design more modes (aka, test cases), right?

Modes and testcases are not the same. See patches 2 and 3. Modes are
mostly for being extensible in a sense of expect the unexpected. I don't
have too may ideas for modes (one more I can think of could be some tee
like proxy for doing whatever kind of assertions/analysis on what some
driver does).  In the previous round we said we want this extensible, and
it make sense.


> 
> If nobody disagrees with the basic idea of this series, I can start a
> review then. ;)
> 
> [...]
>