From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 95D27C432C0 for ; Fri, 22 Nov 2019 11:14:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6ADBF2070E for ; Fri, 22 Nov 2019 11:14:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="hhyYjlxI" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728091AbfKVLN7 (ORCPT ); Fri, 22 Nov 2019 06:13:59 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:55911 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727567AbfKVKyd (ORCPT ); Fri, 22 Nov 2019 05:54:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574420073; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2e50LNZlNp4nrLqKzGHubkeP3g5mGFC99jlbb5R6lfg=; b=hhyYjlxIVnTuvuBIajEWnpxNnmeH8t1gEKXm9LloDOYwiGv0C58FdPAZUeEgaZFyJgBrwN 0POE8MIIKcSpXm6nJHfA1y6p4d3rceVWBZZ0YU4PwDRaicQAhThdUTIkzjkQi10AXdDg9W VHqtuGQsDfR7lnuSGkrjuhDATWKagXY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-276-U4uacRPQO-G9glMmLVTrhw-1; Fri, 22 Nov 2019 05:54:30 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CB2C218557C0; Fri, 22 Nov 2019 10:54:28 +0000 (UTC) Received: from gondolin (dhcp-192-218.str.redhat.com [10.33.192.218]) by smtp.corp.redhat.com (Postfix) with ESMTP id 041971C957; Fri, 22 Nov 2019 10:54:24 +0000 (UTC) Date: Fri, 22 Nov 2019 11:54:22 +0100 From: Cornelia Huck To: Pierre Morel Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org, frankja@linux.ibm.com, david@redhat.com, thuth@redhat.com 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> Organization: Red Hat GmbH MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-MC-Unique: U4uacRPQO-G9glMmLVTrhw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org 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.