On Fri, 22 Nov 2019 10:03:21 +0100 Pierre Morel <pmorel@xxxxxxxxxxxxx> wrote: > On 2019-11-21 17:02, Cornelia Huck wrote: > > On Thu, 14 Nov 2019 11:11:18 +0100 > > Pierre Morel <pmorel@xxxxxxxxxxxxx> wrote: > > > >> On 2019-11-13 14:05, Cornelia Huck wrote: > >>> On Wed, 13 Nov 2019 13:23:19 +0100 > >>> Pierre Morel <pmorel@xxxxxxxxxxxxx> 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.
