From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:30387 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728221AbfKVKye (ORCPT ); Fri, 22 Nov 2019 05:54:34 -0500 Date: Fri, 22 Nov 2019 11:54:22 +0100 From: Cornelia Huck Subject: Re: [PATCH v1 4/4] s390x: Testing the Subchannel I/O read Message-ID: <20191122115422.56019f03.cohuck@redhat.com> In-Reply-To: <0c9d19ef-8ef7-0dab-b283-3db243b95476@linux.ibm.com> References: <1573647799-30584-1-git-send-email-pmorel@linux.ibm.com> <1573647799-30584-5-git-send-email-pmorel@linux.ibm.com> <20191113140539.4d153d5f.cohuck@redhat.com> <802c298d-d2da-83c4-c222-67bb78131988@linux.ibm.com> <20191121170237.72e0bd45.cohuck@redhat.com> <0c9d19ef-8ef7-0dab-b283-3db243b95476@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Sender: linux-s390-owner@vger.kernel.org List-ID: To: Pierre Morel Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org, frankja@linux.ibm.com, david@redhat.com, thuth@redhat.com On Fri, 22 Nov 2019 10:03:21 +0100 Pierre Morel wrote: > On 2019-11-21 17:02, Cornelia Huck wrote: > > On Thu, 14 Nov 2019 11:11:18 +0100 > > Pierre Morel wrote: > > =20 > >> On 2019-11-13 14:05, Cornelia Huck wrote: =20 > >>> On Wed, 13 Nov 2019 13:23:19 +0100 > >>> Pierre Morel wrote: > >>>> - initializing the ORB pointing to a single READ CCW =20 > >>> Out of curiosity: Would using a NOP also be an option? =20 > >> It will work but will not be handled by this device, css.c intercept i= t > >> 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 wi= th > >> 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. =20 > > 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 :) =20 >=20 > The first goal is to test basic I/O from inside the kvm-unit-test,=20 > producing errors and see how the system respond to errors. >=20 > In a standard system errors will be generated by QEMU analysing the I/O= =20 > instruction after interception. >=20 > In a secured guest, we expect the same errors, however we want to check= =20 > 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=20 > 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. =20 >=20 > Writing a VIRTIO driver inside the kvm-unit-test is something we can do= =20 > in the future. >=20 > As you said, the common code already handle NOP and TIC, the=20 > 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: >=20 > in kvm-unit-test: implement all I/O instructions and force instructions= =20 > errors, like memory error, operand etc. and expect the right reaction of= =20 > the system. >=20 > in QEMU, add the necessary infrastructure to test this. Sounds good to me.