Re: [PATCH v1 4/4] s390x: Testing the Subchannel I/O read

[Cornelia Huck <cohuck@redhat.com>]

On Fri, 22 Nov 2019 10:03:21 +0100
Pierre Morel <pmorel@linux.ibm.com> wrote:

> On 2019-11-21 17:02, Cornelia Huck wrote:
> > On Thu, 14 Nov 2019 11:11:18 +0100
> > Pierre Morel <pmorel@linux.ibm.com> wrote:
> >  
> >> On 2019-11-13 14:05, Cornelia Huck wrote:  
> >>> On Wed, 13 Nov 2019 13:23:19 +0100
> >>> Pierre Morel <pmorel@linux.ibm.com> wrote:

> >>>> - initializing the ORB pointing to a single READ CCW  
> >>> Out of curiosity: Would using a NOP also be an option?  
> >> It will work but will not be handled by this device, css.c intercept it
> >> in sch_handle_start_func_virtual.
> >>
> >> AFAIU If we want to have a really good testing environment, for driver
> >> testing for exemple, then it would be interesting to add a new
> >> do_subchannel_work callback like do_subchannel_work_emulation along with
> >> the _virtual and _paththrough variantes.
> >>
> >> Having a dedicated callback for emulation, we can answer to any CSS
> >> instructions and SSCH commands, including NOP and TIC.  
> > I guess that depends on what you want to test; if you actually want to
> > test device emulation as used by virtio etc., you obviously want to go
> > through the existing _virtual callback :)  
> 
> The first goal is to test basic I/O from inside the kvm-unit-test, 
> producing errors and see how the system respond to errors.
> 
> In a standard system errors will be generated by QEMU analysing the I/O 
> instruction after interception.
> 
> In a secured guest, we expect the same errors, however we want to check 
> this.

But we still get the intercepts for all I/O instructions, right? We
just get/inject the parameters in a slightly different way, IIUC.

Not that I disagree with wanting to check this :)

> This PONG device is intended to be low level, no VIRTIO, and to allow 
> basic I/O.

Ok, so this is designed to test basic channel I/O handling, not
necessarily if the guest has set up all its control structures
correctly?

> > The actual motivation behind my question was:
> > Is it possible to e.g. throw NOP (or TIC, or something else not
> > device-specific) at a normal, existing virtio device for test purposes?
> > You'd end up testing the common emulation code without needing any
> > extra support in QEMU. No idea how useful that would be.  
> 
> Writing a VIRTIO driver inside the kvm-unit-test is something we can do 
> in the future.
> 
> As you said, the common code already handle NOP and TIC, the 
> interpretation of the
> CCW chain, once the SSCH has been intercepted is done by QEMU.
> I do not think it would be different with SE.

Yes. You don't really need to get the virtio device up on the virtio
side; if recognizing the device correctly via senseID works and you
maybe can do some NOP/TIC commands, you might have a very basic test
without introducing a new device.

Testing virtio-ccw via kvm-unit-tests is probably a good idea for the
future.

> To sum-up:
> 
> in kvm-unit-test: implement all I/O instructions and force instructions 
> errors, like memory error, operand etc. and expect the right reaction of 
> the system.
> 
> in QEMU, add the necessary infrastructure to test this.

Sounds good to me.