From patchwork Fri Jul 28 09:21:08 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dong Jia Shi X-Patchwork-Id: 794753 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=2001:4830:134:3::11; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3xJjzV12hkz9ryv for ; Fri, 28 Jul 2017 19:22:14 +1000 (AEST) Received: from localhost ([::1]:47005 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1db1TI-0007NR-1K for incoming@patchwork.ozlabs.org; Fri, 28 Jul 2017 05:22:12 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33150) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1db1SS-0007Km-KX for qemu-devel@nongnu.org; Fri, 28 Jul 2017 05:21:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1db1SO-0007DF-D5 for qemu-devel@nongnu.org; Fri, 28 Jul 2017 05:21:20 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:33138) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1db1SO-0007Cg-2x for qemu-devel@nongnu.org; Fri, 28 Jul 2017 05:21:16 -0400 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v6S9JTWX057990 for ; Fri, 28 Jul 2017 05:21:13 -0400 Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by mx0a-001b2d01.pphosted.com with ESMTP id 2byyd3g6my-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 28 Jul 2017 05:21:13 -0400 Received: from localhost by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 28 Jul 2017 03:21:12 -0600 Received: from b03cxnp07028.gho.boulder.ibm.com (9.17.130.15) by e36.co.us.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 28 Jul 2017 03:21:10 -0600 Received: from b03ledav002.gho.boulder.ibm.com (b03ledav002.gho.boulder.ibm.com [9.17.130.233]) by b03cxnp07028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v6S9LApA64815238; Fri, 28 Jul 2017 02:21:10 -0700 Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 32775136044; Fri, 28 Jul 2017 03:21:10 -0600 (MDT) Received: from localhost (unknown [9.115.112.23]) by b03ledav002.gho.boulder.ibm.com (Postfix) with ESMTP id 8378F136043; Fri, 28 Jul 2017 03:21:09 -0600 (MDT) Date: Fri, 28 Jul 2017 17:21:08 +0800 From: Dong Jia Shi To: Cornelia Huck Mail-Followup-To: Cornelia Huck , Dong Jia Shi , qemu-devel@nongnu.org, borntraeger@de.ibm.com, agraf@suse.de, rth@twiddle.net, pasic@linux.vnet.ibm.com, pmorel@linux.vnet.ibm.com References: <20170727015418.85407-1-bjsdjshi@linux.vnet.ibm.com> <20170727114603.77b801e2@gondolin> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170727114603.77b801e2@gondolin> Organization: (IBM CSL) X-URL: http://ibm.com/ User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17072809-0020-0000-0000-00000C748984 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007440; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00894044; UDB=6.00447022; IPR=6.00674204; BA=6.00005495; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016421; XFM=3.00000015; UTC=2017-07-28 09:21:12 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17072809-0021-0000-0000-00005D755276 Message-Id: <20170728092108.GE15504@bjsdjshi@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-28_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707280146 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 148.163.156.1 Subject: Re: [Qemu-devel] [PATCH 0/3] Channel Path realted CRW generation X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: pasic@linux.vnet.ibm.com, pmorel@linux.vnet.ibm.com, qemu-devel@nongnu.org, agraf@suse.de, borntraeger@de.ibm.com, Dong Jia Shi , rth@twiddle.net Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" * Cornelia Huck [2017-07-27 11:46:03 +0200]: > On Thu, 27 Jul 2017 03:54:15 +0200 > Dong Jia Shi wrote: > > > This series is trying to: > > 1. clear up CRW related code. > > 2. generate the right channel path related CRW at the right time. > > > > I did this mainly because it's a requirement from my current work, that is I'm > > in preparation of a group of patch for channel path virtualization. I can use > > the inerface that provided by this series later, so as to, for vfio-ccw > > devices, notify the guest with channel path status vary that happens on the > > host side. > > Sounds cool. > > > > > During an internal discussion, Halil and Pierre pointed out that for path > > hotplug, generating a CRW seems logical, but how is it covered by the AR is not > > clear - we have problem in understanding some grammar ambiguous paragraphs. > > While certain parts of the AR is not available outside, but I'm still wondering > > if the author ;) could give us some clue... BTW, we know that, in Linux kernel > > we had code that handles un-solicited chp crw, so we tend to believe it's right > > to generate channel path initialized CRW for path hotplug. It's just we can not > > find the reason from the document. > > I always found path notifications to be a bit odd. They depend on > various things: > - whether you're running under LPAR or under z/VM > - whether it's a hardware condition (path failure) or something > triggered by the admin (path vary on/off) > - if it's admin triggered, where it was done (on the SE, by one of > several mechanisms in CP, via SCLP) These are clear. During the internnal discussion, we wished to get the resources to test all of these cases to verify. For the z/VM and SE stuff, it seems a bit difficult. So we decided to go with a shortcut -- to ask you. > > You're bound to get different kinds of notifications: via a CRW with > source channel path, via event information retrievable via CHSC > (indicated by a CRW with source CSS), Ha, I was not awre of this one before! > via a PNO indication, or nothing at all. > > [Reminds me of a case where we got path gone CRWs under LPAR when a > path was deactivated at the SE (which we would notice via PNO anyway), > but no CRW when the path was reactivated - not very useful. When trying > to report this as an issue, we got the answer that we of course need to > use the OS interface to vary off the path beforehand. Silly penguins.] ... ... > > My recommendation would be to generate a fitting CRW if the wording > allows to do so. Nod. I'm trying this already. > I would hope that getting as many useful indications as possible is > most helpful to the OS. Nod. Trying this too. My prototype work tries to sync the belowing information from host kernel to qemu: 1. the real SCHIB, so stsch from guest could get the updated path masks. 2. the Store Subchannel Description information, and with the new added support for the SCLP read channel path information command, guest could get the configure status of the path. 3. still working on support CHSC store channel path description command. > (I had added the path-come CRW handling in Linux back then and > afterwards wondered why we did not get it - I must have interpreted > the PoP in the same way as you did.) I've a bugfix patch in the kernel side, and it has been accepted by the s390 maintainers. May be this could be a clue? Post it here: When channel path is identified as the report source code (RSC) of a CRW, and initialized (CRW_ERC_INIT) is recognized as the error recovery code (ERC) by the channel subsystem, it indicates a "path has come" event. Let's handle this case in chp_process_crw(). chsc_chp_online(chpid); Notice: At the very beginning, I replaced CRW_ERC_IPARM with CRW_ERC_INIT. But Sebstian Ott suggested: "I don't know of a machine that actually implements a CRW at all when a chpid is configured online on the SE/HMC. Because of potential regressions I don't want to remove CRW_ERC_IPARM here. I'm good with adding CRW_ERC_INIT though." > > I'll double check with how I'd interpret the PoP today. > Thanks. [...] diff --git a/drivers/s390/cio/chp.c b/drivers/s390/cio/chp.c index 7e0d4f724dda..432fc40990bd 100644 --- a/drivers/s390/cio/chp.c +++ b/drivers/s390/cio/chp.c @@ -559,6 +559,7 @@ static void chp_process_crw(struct crw *crw0, struct crw *crw1, chpid.id = crw0->rsid; switch (crw0->erc) { case CRW_ERC_IPARM: /* Path has come. */ + case CRW_ERC_INIT: if (!chp_is_registered(chpid)) chp_new(chpid);