[{"id":1760721,"web_url":"http://patchwork.ozlabs.org/comment/1760721/","msgid":"","list_archive_url":null,"date":"2017-08-31T07:50:32","subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","submitter":{"id":66152,"url":"http://patchwork.ozlabs.org/api/people/66152/","name":"Thomas Huth","email":"thuth@redhat.com"},"content":"On 30.08.2017 18:36, Halil Pasic wrote:\n> According to the POP a start subchannel instruction (SSCH) returning with\n> cc 1 implies that the subchannel was status pending when SSCH executed.\n> \n> Due to a somewhat confusing error handling, where error codes are mapped\n> to cc value, sane looking error codes result in non AR compliant\n> behavior.\n> \n> Let's fix this! Instead of cc 1 we use cc 3 which means device not\n> operational, and is much closer to the truth in the given cases.\n> \n> Signed-off-by: Halil Pasic \n> Acked-by: Pierre Morel\n> ---\n> \n> This patch turned out quite controversial. We did not reach a consensus\n> during the internal review.\n> \n> The most of the discussion revolved around the ORB flag which\n> architecturally must be supported, but are currently not supported by\n> vfio-ccw (not yet, or can't be). The idea showing the most promise for\n> consensus was to handle this via device status (along the lines better a\n> strange acting device than a non-conform machine) but since it's a\n> radical change we decided to first discuss upstream and then do whatever\n> needs to be done.\n> ---\n> hw/s390x/css.c | 15 ++++++---------\n> hw/s390x/s390-ccw.c | 2 +-\n> 2 files changed, 7 insertions(+), 10 deletions(-)\n> \n> diff --git a/hw/s390x/css.c b/hw/s390x/css.c\n> index a50fb0727e..0822538cde 100644\n> --- a/hw/s390x/css.c\n> +++ b/hw/s390x/css.c\n> @@ -1034,7 +1034,7 @@ static int sch_handle_start_func_passthrough(SubchDev *sch)\n> */\n> if (!(orb->ctrl0 & ORB_CTRL0_MASK_PFCH) ||\n> !(orb->ctrl0 & ORB_CTRL0_MASK_C64)) {\n> - return -EINVAL;\n> + return -ENODEV;\n\nI don't really like ENODEV in this case (since the device is apparently\nthere)... but well, since you're later change it again to set cc=3\ndirectly, I guess the temporary ENODEV is ok.\n\n> }\n> \n> ret = s390_ccw_cmd_request(orb, s, sch->driver_data);\n> @@ -1046,16 +1046,13 @@ static int sch_handle_start_func_passthrough(SubchDev *sch)\n> break;\n> case -ENODEV:\n> break;\n> + case -EFAULT:\n> + break;\n\nI think you should mention this in the patch description. Why is EFAULT\nsuddenly handled here?\n\n> case -EACCES:\n> /* Let's reflect an inaccessible host device by cc 3. */\n> - ret = -ENODEV;\n> - break;\n> default:\n> - /*\n> - * All other return codes will trigger a program check,\n> - * or set cc to 1.\n> - */\n> - break;\n> + /* Let's make all other return codes map to cc 3. */\n> + ret = -ENODEV;\n> };\n> \n> return ret;\n> @@ -1115,7 +1112,7 @@ static int do_subchannel_work(SubchDev *sch)\n> if (sch->do_subchannel_work) {\n> return sch->do_subchannel_work(sch);\n> } else {\n> - return -EINVAL;\n> + return -ENODEV;\n> }\n> }\n> \n> diff --git a/hw/s390x/s390-ccw.c b/hw/s390x/s390-ccw.c\n> index 8614dda6f8..2b0741741c 100644\n> --- a/hw/s390x/s390-ccw.c\n> +++ b/hw/s390x/s390-ccw.c\n> @@ -25,7 +25,7 @@ int s390_ccw_cmd_request(ORB *orb, SCSW *scsw, void *data)\n> if (cdc->handle_request) {\n> return cdc->handle_request(orb, scsw, data);\n> } else {\n> - return -ENOSYS;\n> + return -ENODEV;\n> }\n> }\n\n Thomas","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx06.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx06.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=thuth@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xjZLY5Z6Kz9sNr\n\tfor ;\n\tThu, 31 Aug 2017 17:51:01 +1000 (AEST)","from localhost ([::1]:54371 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dnKFf-0003SB-Vk\n\tfor incoming@patchwork.ozlabs.org; Thu, 31 Aug 2017 03:51:00 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:36404)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dnKFM-0003S6-Bj\n\tfor qemu-devel@nongnu.org; Thu, 31 Aug 2017 03:50:41 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dnKFJ-0008Ms-5u\n\tfor qemu-devel@nongnu.org; Thu, 31 Aug 2017 03:50:40 -0400","from mx1.redhat.com ([209.132.183.28]:41060)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dnKFI-0008Lt-P8\n\tfor qemu-devel@nongnu.org; Thu, 31 Aug 2017 03:50:37 -0400","from smtp.corp.redhat.com\n\t(int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 951E1356D4;\n\tThu, 31 Aug 2017 07:50:35 +0000 (UTC)","from [10.36.116.27] (ovpn-116-27.ams2.redhat.com [10.36.116.27])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id 52855A2461;\n\tThu, 31 Aug 2017 07:50:34 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 951E1356D4","To":"Halil Pasic , Cornelia Huck ","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-3-pasic@linux.vnet.ibm.com>","From":"Thomas Huth ","Message-ID":"","Date":"Thu, 31 Aug 2017 09:50:32 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170830163609.50260-3-pasic@linux.vnet.ibm.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.13","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.30]);\n\tThu, 31 Aug 2017 07:50:35 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Dong Jia Shi ,\n\tPierre Morel , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1760774,"web_url":"http://patchwork.ozlabs.org/comment/1760774/","msgid":"<20170831111953.242ddc28.cohuck@redhat.com>","list_archive_url":null,"date":"2017-08-31T09:19:53","subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","submitter":{"id":71914,"url":"http://patchwork.ozlabs.org/api/people/71914/","name":"Cornelia Huck","email":"cohuck@redhat.com"},"content":"On Wed, 30 Aug 2017 18:36:02 +0200\nHalil Pasic wrote:\n\n> According to the POP a start subchannel instruction (SSCH) returning with\n> cc 1 implies that the subchannel was status pending when SSCH executed.\n> \n> Due to a somewhat confusing error handling, where error codes are mapped\n> to cc value, sane looking error codes result in non AR compliant\n> behavior.\n> \n> Let's fix this! Instead of cc 1 we use cc 3 which means device not\n> operational, and is much closer to the truth in the given cases.\n> \n> Signed-off-by: Halil Pasic \n> Acked-by: Pierre Morel\n> ---\n> \n> This patch turned out quite controversial. We did not reach a consensus\n> during the internal review.\n> \n> The most of the discussion revolved around the ORB flag which\n> architecturally must be supported, but are currently not supported by\n> vfio-ccw (not yet, or can't be). The idea showing the most promise for\n> consensus was to handle this via device status (along the lines better a\n> strange acting device than a non-conform machine) but since it's a\n> radical change we decided to first discuss upstream and then do whatever\n> needs to be done.\n> ---\n> hw/s390x/css.c | 15 ++++++---------\n> hw/s390x/s390-ccw.c | 2 +-\n> 2 files changed, 7 insertions(+), 10 deletions(-)\n> \n> diff --git a/hw/s390x/css.c b/hw/s390x/css.c\n> index a50fb0727e..0822538cde 100644\n> --- a/hw/s390x/css.c\n> +++ b/hw/s390x/css.c\n> @@ -1034,7 +1034,7 @@ static int sch_handle_start_func_passthrough(SubchDev *sch)\n> */\n> if (!(orb->ctrl0 & ORB_CTRL0_MASK_PFCH) ||\n> !(orb->ctrl0 & ORB_CTRL0_MASK_C64)) {\n> - return -EINVAL;\n> + return -ENODEV;\n\nThis feels wrong. If we don't support this yet, doing something like a\nchannel-program check or an operand exception feels closer to the\narchitecture than indicating a gone device.\n\n> }\n> \n> ret = s390_ccw_cmd_request(orb, s, sch->driver_data);\n> @@ -1046,16 +1046,13 @@ static int sch_handle_start_func_passthrough(SubchDev *sch)\n> break;\n> case -ENODEV:\n> break;\n> + case -EFAULT:\n> + break;\n> case -EACCES:\n> /* Let's reflect an inaccessible host device by cc 3. */\n> - ret = -ENODEV;\n> - break;\n> default:\n> - /*\n> - * All other return codes will trigger a program check,\n> - * or set cc to 1.\n> - */\n> - break;\n> + /* Let's make all other return codes map to cc 3. */\n> + ret = -ENODEV;\n\nWhy? This feels wrong. For those cases where we want to signal an error\nbut cc 1 is conceptually wrong, either an operand exception (for very\nfew cases) or a channel-program check feels more in line with the\narchitecture.\n\nThat's a general problem with doing stuff in the hypervisor: We have\nsets of internal problems that obviously don't show up in the\narchitecture, and we can either handle them internally or use what the\narchitecture offers for problem signaling. z/VM has probably faced the\nsame problems :)\n\n> };\n> \n> return ret;\n> @@ -1115,7 +1112,7 @@ static int do_subchannel_work(SubchDev *sch)\n> if (sch->do_subchannel_work) {\n> return sch->do_subchannel_work(sch);\n> } else {\n> - return -EINVAL;\n> + return -ENODEV;\n\nThis rather seems like a job for an assert? If we don't have a function\nfor the 'asynchronous' handling of the various functions assigned for a\nsubchannel, that looks like an internal error.\n\n> }\n> }\n> \n> diff --git a/hw/s390x/s390-ccw.c b/hw/s390x/s390-ccw.c\n> index 8614dda6f8..2b0741741c 100644\n> --- a/hw/s390x/s390-ccw.c\n> +++ b/hw/s390x/s390-ccw.c\n> @@ -25,7 +25,7 @@ int s390_ccw_cmd_request(ORB *orb, SCSW *scsw, void *data)\n> if (cdc->handle_request) {\n> return cdc->handle_request(orb, scsw, data);\n> } else {\n> - return -ENOSYS;\n> + return -ENODEV;\n\nIf we get here, it means that we called a request handler (which is\nonly done for the passthrough variety) without having assigned a\nrequest handler beforehand. This also looks like an internal error to\nme...\n\n> }\n> }\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx01.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx01.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=cohuck@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xjcLM1dmcz9s2G\n\tfor ;\n\tThu, 31 Aug 2017 19:20:59 +1000 (AEST)","from localhost ([::1]:54626 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dnLej-0004kF-Ae\n\tfor incoming@patchwork.ozlabs.org; Thu, 31 Aug 2017 05:20:57 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:54015)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dnLdq-0004Bo-3Q\n\tfor qemu-devel@nongnu.org; Thu, 31 Aug 2017 05:20:06 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dnLdm-0008Pj-Q3\n\tfor qemu-devel@nongnu.org; Thu, 31 Aug 2017 05:20:02 -0400","from mx1.redhat.com ([209.132.183.28]:37282)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dnLdm-0008PQ-HA\n\tfor qemu-devel@nongnu.org; Thu, 31 Aug 2017 05:19:58 -0400","from smtp.corp.redhat.com\n\t(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id C0FDB81DEE;\n\tThu, 31 Aug 2017 09:19:56 +0000 (UTC)","from gondolin (dhcp-192-215.str.redhat.com [10.33.192.215])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id DA360841A1;\n\tThu, 31 Aug 2017 09:19:55 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com C0FDB81DEE","Date":"Thu, 31 Aug 2017 11:19:53 +0200","From":"Cornelia Huck ","To":"Halil Pasic ","Message-ID":"<20170831111953.242ddc28.cohuck@redhat.com>","In-Reply-To":"<20170830163609.50260-3-pasic@linux.vnet.ibm.com>","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-3-pasic@linux.vnet.ibm.com>","Organization":"Red Hat GmbH","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.12","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.25]);\n\tThu, 31 Aug 2017 09:19:56 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Dong Jia Shi ,\n\tPierre Morel , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1760862,"web_url":"http://patchwork.ozlabs.org/comment/1760862/","msgid":"","list_archive_url":null,"date":"2017-08-31T10:41:05","subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","submitter":{"id":68297,"url":"http://patchwork.ozlabs.org/api/people/68297/","name":"Halil Pasic","email":"pasic@linux.vnet.ibm.com"},"content":"On 08/31/2017 11:19 AM, Cornelia Huck wrote:\n> On Wed, 30 Aug 2017 18:36:02 +0200\n> Halil Pasic wrote:\n> \n>> According to the POP a start subchannel instruction (SSCH) returning with\n>> cc 1 implies that the subchannel was status pending when SSCH executed.\n>>\n>> Due to a somewhat confusing error handling, where error codes are mapped\n>> to cc value, sane looking error codes result in non AR compliant\n>> behavior.\n>>\n>> Let's fix this! Instead of cc 1 we use cc 3 which means device not\n>> operational, and is much closer to the truth in the given cases.\n>>\n>> Signed-off-by: Halil Pasic \n>> Acked-by: Pierre Morel\n>> ---\n>>\n>> This patch turned out quite controversial. We did not reach a consensus\n>> during the internal review.\n>>\n>> The most of the discussion revolved around the ORB flag which\n>> architecturally must be supported, but are currently not supported by\n>> vfio-ccw (not yet, or can't be). The idea showing the most promise for\n>> consensus was to handle this via device status (along the lines better a\n>> strange acting device than a non-conform machine) but since it's a\n>> radical change we decided to first discuss upstream and then do whatever\n>> needs to be done.\n>> ---\n>> hw/s390x/css.c | 15 ++++++---------\n>> hw/s390x/s390-ccw.c | 2 +-\n>> 2 files changed, 7 insertions(+), 10 deletions(-)\n>>\n>> diff --git a/hw/s390x/css.c b/hw/s390x/css.c\n>> index a50fb0727e..0822538cde 100644\n>> --- a/hw/s390x/css.c\n>> +++ b/hw/s390x/css.c\n>> @@ -1034,7 +1034,7 @@ static int sch_handle_start_func_passthrough(SubchDev *sch)\n>> */\n>> if (!(orb->ctrl0 & ORB_CTRL0_MASK_PFCH) ||\n>> !(orb->ctrl0 & ORB_CTRL0_MASK_C64)) {\n>> - return -EINVAL;\n>> + return -ENODEV;\n> \n> This feels wrong. If we don't support this yet, doing something like a\n> channel-program check or an operand exception feels closer to the\n> architecture than indicating a gone device.\n\nI disagree, a channel-program check or an operand exception, or cc 1\n(current solution) makes the machine obviously non-conform.\n\nMy train of thought was that architecturally you can loose connection\nto the device at any time (you can't prohibit admins pulling cables or\nsmashing equipment with a 10kg hammer).\n\nAlso from the guest OS perspective I think saying device not operational\ncould provoke a proper reaction form the guest OS: that is just give up\non the device. The things you propose would in my opinion put the blame\non the guest OS driver (making non-conform requests) so in that case\nit would make sense to give up on the driver (but the same driver could\nwonderfully work with let's say a fully emulated device).\n\nAs I have stated in the cover letter of this patch, I would find\nsetting device status even better, but I wanted to discuss first\nbefore going from setting cc to something else.\n\nSetting cc was not my idea in the first place (AFAIK the -EINVAL\nhere effectively triggers cc 1).\n\n> \n>> }\n>> \n>> ret = s390_ccw_cmd_request(orb, s, sch->driver_data);\n>> @@ -1046,16 +1046,13 @@ static int sch_handle_start_func_passthrough(SubchDev *sch)\n>> break;\n>> case -ENODEV:\n>> break;\n>> + case -EFAULT:\n>> + break;\n>> case -EACCES:\n>> /* Let's reflect an inaccessible host device by cc 3. */\n>> - ret = -ENODEV;\n>> - break;\n>> default:\n>> - /*\n>> - * All other return codes will trigger a program check,\n>> - * or set cc to 1.\n>> - */\n>> - break;\n>> + /* Let's make all other return codes map to cc 3. */\n>> + ret = -ENODEV;\n> \n> Why? This feels wrong. For those cases where we want to signal an error\n> but cc 1 is conceptually wrong, either an operand exception (for very\n> few cases) or a channel-program check feels more in line with the\n> architecture.\n\nYou mean the original code feels wrong, or? I keep the program check for\n-EFAULT (that's why it's added) and just change cc 1 to cc 3 for the\nnot explicitly handled error codes (reason stated in the commit message).\n\n> \n> That's a general problem with doing stuff in the hypervisor: We have\n> sets of internal problems that obviously don't show up in the\n> architecture, and we can either handle them internally or use what the\n> architecture offers for problem signaling. z/VM has probably faced the\n> same problems :)\n\nI agree.\n\n> \n>> };\n>> \n>> return ret;\n>> @@ -1115,7 +1112,7 @@ static int do_subchannel_work(SubchDev *sch)\n>> if (sch->do_subchannel_work) {\n>> return sch->do_subchannel_work(sch);\n>> } else {\n>> - return -EINVAL;\n>> + return -ENODEV;\n> \n> This rather seems like a job for an assert? If we don't have a function\n> for the 'asynchronous' handling of the various functions assigned for a\n> subchannel, that looks like an internal error.\n> \n\nIMHO it depends. Aborting qemu is heavy handed, and as an user I would not\nbe happy about it. But certainly it is an assert situation. We can look for\nan even better solution, but I think this is an improvement. The logic behind\nis that the device is broken and can't be talked to properly.\n\n>> }\n>> }\n>> \n>> diff --git a/hw/s390x/s390-ccw.c b/hw/s390x/s390-ccw.c\n>> index 8614dda6f8..2b0741741c 100644\n>> --- a/hw/s390x/s390-ccw.c\n>> +++ b/hw/s390x/s390-ccw.c\n>> @@ -25,7 +25,7 @@ int s390_ccw_cmd_request(ORB *orb, SCSW *scsw, void *data)\n>> if (cdc->handle_request) {\n>> return cdc->handle_request(orb, scsw, data);\n>> } else {\n>> - return -ENOSYS;\n>> + return -ENODEV;\n> \n> If we get here, it means that we called a request handler (which is\n> only done for the passthrough variety) without having assigned a\n> request handler beforehand. This also looks like an internal error to\n> me...\n> \n\nCertainly. Again I was not the one who wrote or accepted the original\ncode. My previous comment about whether assert or not applies here as\nwell.\n\n>> }\n>> }\n>> \n> \n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xjgTx690Jz9sQl\n\tfor ;\n\tThu, 31 Aug 2017 21:42:45 +1000 (AEST)","from localhost ([::1]:54971 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dnN8j-0007e4-Ff\n\tfor incoming@patchwork.ozlabs.org; Thu, 31 Aug 2017 06:56:01 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:43406)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dnMuS-0007Ey-Jy\n\tfor qemu-devel@nongnu.org; Thu, 31 Aug 2017 06:41:18 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dnMuN-0008RS-N8\n\tfor qemu-devel@nongnu.org; Thu, 31 Aug 2017 06:41:16 -0400","from mx0b-001b2d01.pphosted.com ([148.163.158.5]:37987\n\thelo=mx0a-001b2d01.pphosted.com)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dnMuN-0008RF-GT\n\tfor qemu-devel@nongnu.org; Thu, 31 Aug 2017 06:41:11 -0400","from pps.filterd (m0098414.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv7VAcqOA041674\n\tfor ; Thu, 31 Aug 2017 06:41:11 -0400","from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2cpe3mrwu2-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Thu, 31 Aug 2017 06:41:10 -0400","from localhost\n\tby e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tThu, 31 Aug 2017 11:41:09 +0100","from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194)\n\tby e06smtp14.uk.ibm.com (192.168.101.144) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tThu, 31 Aug 2017 11:41:06 +0100","from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com\n\t[9.149.105.61])\n\tby b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v7VAf6sM20775132; Thu, 31 Aug 2017 10:41:06 GMT","from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id E208B11C04C;\n\tThu, 31 Aug 2017 11:37:35 +0100 (BST)","from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id B037811C04A;\n\tThu, 31 Aug 2017 11:37:35 +0100 (BST)","from oc3836556865.ibm.com (unknown [9.152.224.207])\n\tby d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP;\n\tThu, 31 Aug 2017 11:37:35 +0100 (BST)"],"To":"Cornelia Huck ","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-3-pasic@linux.vnet.ibm.com>\n\t<20170831111953.242ddc28.cohuck@redhat.com>","From":"Halil Pasic ","Date":"Thu, 31 Aug 2017 12:41:05 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.0","MIME-Version":"1.0","In-Reply-To":"<20170831111953.242ddc28.cohuck@redhat.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","X-TM-AS-GCONF":"00","x-cbid":"17083110-0016-0000-0000-000004E7B03A","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17083110-0017-0000-0000-000028212ECB","Message-Id":"","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-08-31_03:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1708310162","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy]","X-Received-From":"148.163.158.5","Subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Dong Jia Shi ,\n\tPierre Morel , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1760876,"web_url":"http://patchwork.ozlabs.org/comment/1760876/","msgid":"","list_archive_url":null,"date":"2017-08-31T10:54:32","subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","submitter":{"id":68297,"url":"http://patchwork.ozlabs.org/api/people/68297/","name":"Halil Pasic","email":"pasic@linux.vnet.ibm.com"},"content":"On 08/31/2017 09:50 AM, Thomas Huth wrote:\n> On 30.08.2017 18:36, Halil Pasic wrote:\n>> According to the POP a start subchannel instruction (SSCH) returning with\n>> cc 1 implies that the subchannel was status pending when SSCH executed.\n>>\n>> Due to a somewhat confusing error handling, where error codes are mapped\n>> to cc value, sane looking error codes result in non AR compliant\n>> behavior.\n>>\n>> Let's fix this! Instead of cc 1 we use cc 3 which means device not\n>> operational, and is much closer to the truth in the given cases.\n>>\n>> Signed-off-by: Halil Pasic \n>> Acked-by: Pierre Morel\n>> ---\n>>\n>> This patch turned out quite controversial. We did not reach a consensus\n>> during the internal review.\n>>\n>> The most of the discussion revolved around the ORB flag which\n>> architecturally must be supported, but are currently not supported by\n>> vfio-ccw (not yet, or can't be). The idea showing the most promise for\n>> consensus was to handle this via device status (along the lines better a\n>> strange acting device than a non-conform machine) but since it's a\n>> radical change we decided to first discuss upstream and then do whatever\n>> needs to be done.\n>> ---\n>> hw/s390x/css.c | 15 ++++++---------\n>> hw/s390x/s390-ccw.c | 2 +-\n>> 2 files changed, 7 insertions(+), 10 deletions(-)\n>>\n>> diff --git a/hw/s390x/css.c b/hw/s390x/css.c\n>> index a50fb0727e..0822538cde 100644\n>> --- a/hw/s390x/css.c\n>> +++ b/hw/s390x/css.c\n>> @@ -1034,7 +1034,7 @@ static int sch_handle_start_func_passthrough(SubchDev *sch)\n>> */\n>> if (!(orb->ctrl0 & ORB_CTRL0_MASK_PFCH) ||\n>> !(orb->ctrl0 & ORB_CTRL0_MASK_C64)) {\n>> - return -EINVAL;\n>> + return -ENODEV;\n> \n> I don't really like ENODEV in this case (since the device is apparently\n> there)... but well, since you're later change it again to set cc=3\n> directly, I guess the temporary ENODEV is ok.\n> \n>> }\n>> \n>> ret = s390_ccw_cmd_request(orb, s, sch->driver_data);\n>> @@ -1046,16 +1046,13 @@ static int sch_handle_start_func_passthrough(SubchDev *sch)\n>> break;\n>> case -ENODEV:\n>> break;\n>> + case -EFAULT:\n>> + break;\n> \n> I think you should mention this in the patch description. Why is EFAULT\n> suddenly handled here?\n\nIt is not suddenly :) If you examine ioinst_handle_ssch which really\nhandles the error codes (here we are just mapping them around) you see:\n switch (ret) {\n case -ENODEV:\n cc = 3;\n break;\n case -EBUSY:\n cc = 2;\n break;\n case -EFAULT:\n /*\n * TODO:\n * I'm wondering whether there is something better\n * to do for us here (like setting some device or\n * subchannel status).\n */\n program_interrupt(env, PGM_ADDRESSING, 4);\n return;\n case 0:\n cc = 0;\n break;\n default:\n cc = 1;\n break;\n }\n\nThat is -EFAULT is handled with a program interrupt, and I want to keep\nthat. Hence break, that is keep unchanged.\n\nWhat I do want to change is the other not explicitly handled error codes\n(which actually should not happen) should be cc 3 and not cc 1.\n\nSo the default branch sets ret to -ENODEV.\n\n\n> \n>> case -EACCES:\n>> /* Let's reflect an inaccessible host device by cc 3. */\n>> - ret = -ENODEV;\n>> - break;\n>> default:\n>> - /*\n>> - * All other return codes will trigger a program check,\n>> - * or set cc to 1.\n>> - */\n>> - break;\n>> + /* Let's make all other return codes map to cc 3. */\n>> + ret = -ENODEV;\n>> };\n>> \n>> return ret;\n>> @@ -1115,7 +1112,7 @@ static int do_subchannel_work(SubchDev *sch)\n>> if (sch->do_subchannel_work) {\n>> return sch->do_subchannel_work(sch);\n>> } else {\n>> - return -EINVAL;\n>> + return -ENODEV;\n>> }\n>> }\n>> \n>> diff --git a/hw/s390x/s390-ccw.c b/hw/s390x/s390-ccw.c\n>> index 8614dda6f8..2b0741741c 100644\n>> --- a/hw/s390x/s390-ccw.c\n>> +++ b/hw/s390x/s390-ccw.c\n>> @@ -25,7 +25,7 @@ int s390_ccw_cmd_request(ORB *orb, SCSW *scsw, void *data)\n>> if (cdc->handle_request) {\n>> return cdc->handle_request(orb, scsw, data);\n>> } else {\n>> - return -ENOSYS;\n>> + return -ENODEV;\n>> }\n>> }\n> \n> Thomas\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xjgld4NLRz9t16\n\tfor ;\n\tThu, 31 Aug 2017 21:54:37 +1000 (AEST)","from localhost ([::1]:55177 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dnO3P-0007r4-Ph\n\tfor incoming@patchwork.ozlabs.org; Thu, 31 Aug 2017 07:54:35 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:47003)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dnN7V-0007a4-IS\n\tfor qemu-devel@nongnu.org; Thu, 31 Aug 2017 06:54:46 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dnN7Q-00040z-Ln\n\tfor qemu-devel@nongnu.org; Thu, 31 Aug 2017 06:54:45 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:33537)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dnN7Q-00040k-Cl\n\tfor qemu-devel@nongnu.org; Thu, 31 Aug 2017 06:54:40 -0400","from pps.filterd (m0098399.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv7VAsYqX116641\n\tfor ; Thu, 31 Aug 2017 06:54:39 -0400","from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2cpfgp5h59-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Thu, 31 Aug 2017 06:54:38 -0400","from localhost\n\tby e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tThu, 31 Aug 2017 11:54:35 +0100","from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194)\n\tby e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tThu, 31 Aug 2017 11:54:33 +0100","from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com\n\t[9.149.105.232])\n\tby b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v7VAsX2214090354; Thu, 31 Aug 2017 10:54:33 GMT","from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 2DAE552045;\n\tThu, 31 Aug 2017 10:49:59 +0100 (BST)","from oc3836556865.ibm.com (unknown [9.152.224.207])\n\tby d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id CA4B152043; \n\tThu, 31 Aug 2017 10:49:58 +0100 (BST)"],"To":"Thomas Huth , Cornelia Huck ","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-3-pasic@linux.vnet.ibm.com>\n\t","From":"Halil Pasic ","Date":"Thu, 31 Aug 2017 12:54:32 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","X-TM-AS-GCONF":"00","x-cbid":"17083110-0012-0000-0000-00000573AD55","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17083110-0013-0000-0000-000018EBD370","Message-Id":"","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-08-31_03:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1708310166","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 2/9] s390x: fix invalid use of cc 1 for SSCH","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Dong Jia Shi ,\n\tPierre Morel , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1763046,"web_url":"http://patchwork.ozlabs.org/comment/1763046/","msgid":"<20170905100234.7a92128e.cohuck@redhat.com>","list_archive_url":null,"date":"2017-09-05T08:02:34","subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","submitter":{"id":71914,"url":"http://patchwork.ozlabs.org/api/people/71914/","name":"Cornelia Huck","email":"cohuck@redhat.com"},"content":"On Thu, 31 Aug 2017 12:41:05 +0200\nHalil Pasic wrote:\n\n> On 08/31/2017 11:19 AM, Cornelia Huck wrote:\n> > On Wed, 30 Aug 2017 18:36:02 +0200\n> > Halil Pasic wrote:\n> > \n> >> According to the POP a start subchannel instruction (SSCH) returning with\n> >> cc 1 implies that the subchannel was status pending when SSCH executed.\n> >>\n> >> Due to a somewhat confusing error handling, where error codes are mapped\n> >> to cc value, sane looking error codes result in non AR compliant\n> >> behavior.\n> >>\n> >> Let's fix this! Instead of cc 1 we use cc 3 which means device not\n> >> operational, and is much closer to the truth in the given cases.\n> >>\n> >> Signed-off-by: Halil Pasic \n> >> Acked-by: Pierre Morel\n> >> ---\n> >>\n> >> This patch turned out quite controversial. We did not reach a consensus\n> >> during the internal review.\n> >>\n> >> The most of the discussion revolved around the ORB flag which\n> >> architecturally must be supported, but are currently not supported by\n> >> vfio-ccw (not yet, or can't be). The idea showing the most promise for\n> >> consensus was to handle this via device status (along the lines better a\n> >> strange acting device than a non-conform machine) but since it's a\n> >> radical change we decided to first discuss upstream and then do whatever\n> >> needs to be done.\n> >> ---\n> >> hw/s390x/css.c | 15 ++++++---------\n> >> hw/s390x/s390-ccw.c | 2 +-\n> >> 2 files changed, 7 insertions(+), 10 deletions(-)\n> >>\n> >> diff --git a/hw/s390x/css.c b/hw/s390x/css.c\n> >> index a50fb0727e..0822538cde 100644\n> >> --- a/hw/s390x/css.c\n> >> +++ b/hw/s390x/css.c\n> >> @@ -1034,7 +1034,7 @@ static int sch_handle_start_func_passthrough(SubchDev *sch)\n> >> */\n> >> if (!(orb->ctrl0 & ORB_CTRL0_MASK_PFCH) ||\n> >> !(orb->ctrl0 & ORB_CTRL0_MASK_C64)) {\n> >> - return -EINVAL;\n> >> + return -ENODEV; \n> > \n> > This feels wrong. If we don't support this yet, doing something like a\n> > channel-program check or an operand exception feels closer to the\n> > architecture than indicating a gone device. \n> \n> I disagree, a channel-program check or an operand exception, or cc 1\n> (current solution) makes the machine obviously non-conform.\n\nWell, it *is* not compliant...\n\n> \n> My train of thought was that architecturally you can loose connection\n> to the device at any time (you can't prohibit admins pulling cables or\n> smashing equipment with a 10kg hammer).\n\nBut that's not what you're doing: Iff you want to signal 'device\ngone' (and I'm not convinced it's a good idea), you need to do more\nthan signal cc 3.\n\n> \n> Also from the guest OS perspective I think saying device not operational\n> could provoke a proper reaction form the guest OS: that is just give up\n> on the device. The things you propose would in my opinion put the blame\n> on the guest OS driver (making non-conform requests) so in that case\n> it would make sense to give up on the driver (but the same driver could\n> wonderfully work with let's say a fully emulated device).\n\nI'd not call that 'putting blame on the driver'. What happens is that\nwe signal the driver 'you send us something we cannot deal with' - the\nmore common reason for that is that the driver built an invalid\nrequest, but I've certainly seen rejects for stuff that simply was not\nimplemented in the past.\n\nThe important thing is that I don't want to lie to the driver: The\ndevice is there, and will work with a different request. Also see my\ncomment above.\n\n(The real fix is of course to implement what is required by the\narchitecture :), but I don't think cc 3 is a good stop-gap measure.)\n\n> \n> As I have stated in the cover letter of this patch, I would find\n> setting device status even better, but I wanted to discuss first\n> before going from setting cc to something else.\n> \n> Setting cc was not my idea in the first place (AFAIK the -EINVAL\n> here effectively triggers cc 1).\n\nSomething else than cc 1 is better, yes (but the intention was probably\na channel-program check or so).\n\n> \n> > \n> >> }\n> >> \n> >> ret = s390_ccw_cmd_request(orb, s, sch->driver_data);\n> >> @@ -1046,16 +1046,13 @@ static int sch_handle_start_func_passthrough(SubchDev *sch)\n> >> break;\n> >> case -ENODEV:\n> >> break;\n> >> + case -EFAULT:\n> >> + break;\n> >> case -EACCES:\n> >> /* Let's reflect an inaccessible host device by cc 3. */\n> >> - ret = -ENODEV;\n> >> - break;\n> >> default:\n> >> - /*\n> >> - * All other return codes will trigger a program check,\n> >> - * or set cc to 1.\n> >> - */\n> >> - break;\n> >> + /* Let's make all other return codes map to cc 3. */\n> >> + ret = -ENODEV; \n> > \n> > Why? This feels wrong. For those cases where we want to signal an error\n> > but cc 1 is conceptually wrong, either an operand exception (for very\n> > few cases) or a channel-program check feels more in line with the\n> > architecture. \n> \n> You mean the original code feels wrong, or? I keep the program check for\n> -EFAULT (that's why it's added) and just change cc 1 to cc 3 for the\n> not explicitly handled error codes (reason stated in the commit message).\n\nI mean that both feel wrong :) Moving away from abuses of cc 1 makes\nsense, but I don't think cc 3 is the correct direction.\n\n> \n> > \n> > That's a general problem with doing stuff in the hypervisor: We have\n> > sets of internal problems that obviously don't show up in the\n> > architecture, and we can either handle them internally or use what the\n> > architecture offers for problem signaling. z/VM has probably faced the\n> > same problems :) \n> \n> I agree.\n> \n> > \n> >> };\n> >> \n> >> return ret;\n> >> @@ -1115,7 +1112,7 @@ static int do_subchannel_work(SubchDev *sch)\n> >> if (sch->do_subchannel_work) {\n> >> return sch->do_subchannel_work(sch);\n> >> } else {\n> >> - return -EINVAL;\n> >> + return -ENODEV; \n> > \n> > This rather seems like a job for an assert? If we don't have a function\n> > for the 'asynchronous' handling of the various functions assigned for a\n> > subchannel, that looks like an internal error.\n> > \n> \n> IMHO it depends. Aborting qemu is heavy handed, and as an user I would not\n> be happy about it. But certainly it is an assert situation. We can look for\n> an even better solution, but I think this is an improvement. The logic behind\n> is that the device is broken and can't be talked to properly.\n\nWe currently don't have a vast array of subchannel types (and are\nunlikely to get more types that need a different handler function). We\nknow the current ones are fine, and an assert would catch programming\nerrors early.\n\n> \n> >> }\n> >> }\n> >> \n> >> diff --git a/hw/s390x/s390-ccw.c b/hw/s390x/s390-ccw.c\n> >> index 8614dda6f8..2b0741741c 100644\n> >> --- a/hw/s390x/s390-ccw.c\n> >> +++ b/hw/s390x/s390-ccw.c\n> >> @@ -25,7 +25,7 @@ int s390_ccw_cmd_request(ORB *orb, SCSW *scsw, void *data)\n> >> if (cdc->handle_request) {\n> >> return cdc->handle_request(orb, scsw, data);\n> >> } else {\n> >> - return -ENOSYS;\n> >> + return -ENODEV; \n> > \n> > If we get here, it means that we called a request handler (which is\n> > only done for the passthrough variety) without having assigned a\n> > request handler beforehand. This also looks like an internal error to\n> > me...\n> > \n> \n> Certainly. Again I was not the one who wrote or accepted the original\n> code. My previous comment about whether assert or not applies here as\n> well.\n\nMy answer applies even more here :)","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx04.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx04.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=cohuck@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xmfNT682Tz9s4q\n\tfor ;\n\tTue, 5 Sep 2017 18:03:21 +1000 (AEST)","from localhost ([::1]:57333 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dp8pM-0001cv-17\n\tfor incoming@patchwork.ozlabs.org; Tue, 05 Sep 2017 04:03:20 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:34422)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dp8om-0001YX-2f\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 04:02:52 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dp8og-0005ro-VL\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 04:02:44 -0400","from mx1.redhat.com ([209.132.183.28]:49440)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dp8og-0005rP-Ld\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 04:02:38 -0400","from smtp.corp.redhat.com\n\t(int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 62E3E7EA8B;\n\tTue, 5 Sep 2017 08:02:37 +0000 (UTC)","from gondolin (dhcp-192-215.str.redhat.com [10.33.192.215])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 7A17C4D759;\n\tTue, 5 Sep 2017 08:02:36 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 62E3E7EA8B","Date":"Tue, 5 Sep 2017 10:02:34 +0200","From":"Cornelia Huck ","To":"Halil Pasic ","Message-ID":"<20170905100234.7a92128e.cohuck@redhat.com>","In-Reply-To":"","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-3-pasic@linux.vnet.ibm.com>\n\t<20170831111953.242ddc28.cohuck@redhat.com>\n\t","Organization":"Red Hat GmbH","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.16","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.28]);\n\tTue, 05 Sep 2017 08:02:37 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Dong Jia Shi ,\n\tPierre Morel , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1763446,"web_url":"http://patchwork.ozlabs.org/comment/1763446/","msgid":"","list_archive_url":null,"date":"2017-09-05T15:24:19","subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","submitter":{"id":68297,"url":"http://patchwork.ozlabs.org/api/people/68297/","name":"Halil Pasic","email":"pasic@linux.vnet.ibm.com"},"content":"On 09/05/2017 10:02 AM, Cornelia Huck wrote:\n> On Thu, 31 Aug 2017 12:41:05 +0200\n> Halil Pasic wrote:\n> \n>> On 08/31/2017 11:19 AM, Cornelia Huck wrote:\n>>> On Wed, 30 Aug 2017 18:36:02 +0200\n>>> Halil Pasic wrote:\n>>> \n>>>> According to the POP a start subchannel instruction (SSCH) returning with\n>>>> cc 1 implies that the subchannel was status pending when SSCH executed.\n>>>>\n>>>> Due to a somewhat confusing error handling, where error codes are mapped\n>>>> to cc value, sane looking error codes result in non AR compliant\n>>>> behavior.\n>>>>\n>>>> Let's fix this! Instead of cc 1 we use cc 3 which means device not\n>>>> operational, and is much closer to the truth in the given cases.\n>>>>\n>>>> Signed-off-by: Halil Pasic \n>>>> Acked-by: Pierre Morel\n>>>> ---\n>>>>\n>>>> This patch turned out quite controversial. We did not reach a consensus\n>>>> during the internal review.\n>>>>\n>>>> The most of the discussion revolved around the ORB flag which\n>>>> architecturally must be supported, but are currently not supported by\n>>>> vfio-ccw (not yet, or can't be). The idea showing the most promise for\n>>>> consensus was to handle this via device status (along the lines better a\n>>>> strange acting device than a non-conform machine) but since it's a\n>>>> radical change we decided to first discuss upstream and then do whatever\n>>>> needs to be done.\n>>>> ---\n>>>> hw/s390x/css.c | 15 ++++++---------\n>>>> hw/s390x/s390-ccw.c | 2 +-\n>>>> 2 files changed, 7 insertions(+), 10 deletions(-)\n>>>>\n>>>> diff --git a/hw/s390x/css.c b/hw/s390x/css.c\n>>>> index a50fb0727e..0822538cde 100644\n>>>> --- a/hw/s390x/css.c\n>>>> +++ b/hw/s390x/css.c\n>>>> @@ -1034,7 +1034,7 @@ static int sch_handle_start_func_passthrough(SubchDev *sch)\n>>>> */\n>>>> if (!(orb->ctrl0 & ORB_CTRL0_MASK_PFCH) ||\n>>>> !(orb->ctrl0 & ORB_CTRL0_MASK_C64)) {\n>>>> - return -EINVAL;\n>>>> + return -ENODEV; \n>>>\n>>> This feels wrong. If we don't support this yet, doing something like a\n>>> channel-program check or an operand exception feels closer to the\n>>> architecture than indicating a gone device. \n>>\n>> I disagree, a channel-program check or an operand exception, or cc 1\n>> (current solution) makes the machine obviously non-conform.\n> \n> Well, it *is* not compliant...\n> \n\nI'm trying to explain that could be. It is a design decision whether\nto put the non-compliant in the machine or in the device attached\nto the machine.\n\n>>\n>> My train of thought was that architecturally you can loose connection\n>> to the device at any time (you can't prohibit admins pulling cables or\n>> smashing equipment with a 10kg hammer).\n> \n> But that's not what you're doing: Iff you want to signal 'device\n> gone' (and I'm not convinced it's a good idea), you need to do more\n> than signal cc 3.\n> \n\nValid (probably), but we already use this kind of gone cc 3 (IMHO).\n\n>>\n>> Also from the guest OS perspective I think saying device not operational\n>> could provoke a proper reaction form the guest OS: that is just give up\n>> on the device. The things you propose would in my opinion put the blame\n>> on the guest OS driver (making non-conform requests) so in that case\n>> it would make sense to give up on the driver (but the same driver could\n>> wonderfully work with let's say a fully emulated device).\n> \n> I'd not call that 'putting blame on the driver'. What happens is that\n> we signal the driver 'you send us something we cannot deal with' - the\n> more common reason for that is that the driver built an invalid\n> request, but I've certainly seen rejects for stuff that simply was not\n> implemented in the past.\n\nI assume you are talking about a channel-program check or operand exception\nnow and not about cc 1. IMHO while your argument does make sense, it\ncontradicts the specified architecture. In my reading the architecture \ndefines operand exception and program-check condition as triggered\nsolely by program (OS) error.\n\nYes, if one could re-write the architecture, the cleanest way would probably\nbe capability indication (e.g. can live without prefetching) and channel\nprogram-check if the capability indication is disregarded. But as far as\nI know we can't re-write the architecture.\n\n> \n> The important thing is that I don't want to lie to the driver: The\n> device is there, and will work with a different request. Also see my\n> comment above.\n\nI agree, telling the truth is important. My problem is, that\nall the choice we have seems to be picking a lie. And we seem to not\nagree, which lie is better.\n\n> \n> (The real fix is of course to implement what is required by the\n> architecture :), but I don't think cc 3 is a good stop-gap measure.)\n> \n>>\n>> As I have stated in the cover letter of this patch, I would find\n>> setting device status even better, but I wanted to discuss first\n>> before going from setting cc to something else.\n>>\n>> Setting cc was not my idea in the first place (AFAIK the -EINVAL\n>> here effectively triggers cc 1).\n> \n> Something else than cc 1 is better, yes (but the intention was probably\n> a channel-program check or so).\n> \n\nMy problem with a program check (indicated by SCSW word 2 bit 10) is\nthat, in my reading of the architecture, the semantic behind it is: The\nchannel subsystem (not the cu or device) has detected, that the \nthe channel program (previously submitted as an ORB) is erroneous. Which\nprograms are erroneous is specified by the architecture. What we have\nhere does not qualify.\n\nMy idea was to rather blame the virtual hardware (device) and put no blame\non the program nor he channel subsystem. This could be done using device\nstatus (unit check with command reject, maybe unit exception) or interface\ncheck. My train of thought was, the problem is not consistent across a\ndevice type, so it has to be device specific.\n\nOf course blaming the device could mislead the person encountering the\nproblem, and make him believe it's an non-virtual hardware problem.\n\nAbout the misleading, I think the best we can do is log out a message\nindicating what really happened.\n\nIn the end I don't care that deeply about vfio-ccw, and this problem\nalready took me more time than I intended to spend on this. We have\npeople driving this whole vfio-ccw stuff and I'm not one of them (I'm\nrather in the supporting role).\n\nI'm also fine with me being credited with a reported-by once the\nmore involved people figure out what to do, and keeping the vfio-ccw\nstuff as is. Should we go with that option? \n\n>>\n>>> \n>>>> }\n>>>> \n>>>> ret = s390_ccw_cmd_request(orb, s, sch->driver_data);\n>>>> @@ -1046,16 +1046,13 @@ static int sch_handle_start_func_passthrough(SubchDev *sch)\n>>>> break;\n>>>> case -ENODEV:\n>>>> break;\n>>>> + case -EFAULT:\n>>>> + break;\n>>>> case -EACCES:\n>>>> /* Let's reflect an inaccessible host device by cc 3. */\n>>>> - ret = -ENODEV;\n>>>> - break;\n>>>> default:\n>>>> - /*\n>>>> - * All other return codes will trigger a program check,\n>>>> - * or set cc to 1.\n>>>> - */\n>>>> - break;\n>>>> + /* Let's make all other return codes map to cc 3. */\n>>>> + ret = -ENODEV; \n>>>\n>>> Why? This feels wrong. For those cases where we want to signal an error\n>>> but cc 1 is conceptually wrong, either an operand exception (for very\n>>> few cases) or a channel-program check feels more in line with the\n>>> architecture. \n>>\n>> You mean the original code feels wrong, or? I keep the program check for\n>> -EFAULT (that's why it's added) and just change cc 1 to cc 3 for the\n>> not explicitly handled error codes (reason stated in the commit message).\n> \n> I mean that both feel wrong :) Moving away from abuses of cc 1 makes\n> sense, but I don't think cc 3 is the correct direction.\n> \n\nNoted. Discussed above.\n\n>>\n>>>\n>>> That's a general problem with doing stuff in the hypervisor: We have\n>>> sets of internal problems that obviously don't show up in the\n>>> architecture, and we can either handle them internally or use what the\n>>> architecture offers for problem signaling. z/VM has probably faced the\n>>> same problems :) \n>>\n>> I agree.\n>>\n>>> \n>>>> };\n>>>> \n>>>> return ret;\n>>>> @@ -1115,7 +1112,7 @@ static int do_subchannel_work(SubchDev *sch)\n>>>> if (sch->do_subchannel_work) {\n>>>> return sch->do_subchannel_work(sch);\n>>>> } else {\n>>>> - return -EINVAL;\n>>>> + return -ENODEV; \n>>>\n>>> This rather seems like a job for an assert? If we don't have a function\n>>> for the 'asynchronous' handling of the various functions assigned for a\n>>> subchannel, that looks like an internal error.\n>>> \n>>\n>> IMHO it depends. Aborting qemu is heavy handed, and as an user I would not\n>> be happy about it. But certainly it is an assert situation. We can look for\n>> an even better solution, but I think this is an improvement. The logic behind\n>> is that the device is broken and can't be talked to properly.\n> \n> We currently don't have a vast array of subchannel types (and are\n> unlikely to get more types that need a different handler function). We\n> know the current ones are fine, and an assert would catch programming\n> errors early.\n> \n\nDespite of that we already had a problem of this type: see 1728cff2ab\n(\"s390x/3270: fix instruction interception handler\", 2017-06-09) by \nDong Jia. If we had some automated testing covering all the asserts\nI would not think twice about using an assert here. But I don't think\nwe do and I'm reluctant (not positive that assert is superior to what\nwe have now). Maybe we could agree on reported by again.\n\n>>\n>>>> }\n>>>> }\n>>>> \n>>>> diff --git a/hw/s390x/s390-ccw.c b/hw/s390x/s390-ccw.c\n>>>> index 8614dda6f8..2b0741741c 100644\n>>>> --- a/hw/s390x/s390-ccw.c\n>>>> +++ b/hw/s390x/s390-ccw.c\n>>>> @@ -25,7 +25,7 @@ int s390_ccw_cmd_request(ORB *orb, SCSW *scsw, void *data)\n>>>> if (cdc->handle_request) {\n>>>> return cdc->handle_request(orb, scsw, data);\n>>>> } else {\n>>>> - return -ENOSYS;\n>>>> + return -ENODEV; \n>>>\n>>> If we get here, it means that we called a request handler (which is\n>>> only done for the passthrough variety) without having assigned a\n>>> request handler beforehand. This also looks like an internal error to\n>>> me...\n>>> \n>>\n>> Certainly. Again I was not the one who wrote or accepted the original\n>> code. My previous comment about whether assert or not applies here as\n>> well.\n> \n> My answer applies even more here :)\n> \n\nThis is again vfio-ccw.\n\nI've just noticed that I did not answer to your comments\nfor patch 4. Sorry, I was waiting for more feedback on patches 4-9,\nbut it turns out the ball is in my court. I will do that right away.\n\nRegards,\nHalil","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xmrB63WhRz9ryQ\n\tfor ;\n\tWed, 6 Sep 2017 01:25:02 +1000 (AEST)","from localhost ([::1]:59621 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpFim-00049I-L4\n\tfor incoming@patchwork.ozlabs.org; Tue, 05 Sep 2017 11:25:00 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:46065)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpFiK-00048t-BM\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 11:24:37 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpFiE-0000se-Qj\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 11:24:32 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:58073)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dpFiE-0000rc-HB\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 11:24:26 -0400","from pps.filterd (m0098393.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv85FNht3008250\n\tfor ; Tue, 5 Sep 2017 11:24:25 -0400","from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com [195.75.94.107])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2csu2wbpmf-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Tue, 05 Sep 2017 11:24:25 -0400","from localhost\n\tby e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tTue, 5 Sep 2017 16:24:22 +0100","from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195)\n\tby e06smtp11.uk.ibm.com (192.168.101.141) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tTue, 5 Sep 2017 16:24:20 +0100","from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com\n\t[9.149.105.58])\n\tby b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v85FOJRh8192172; Tue, 5 Sep 2017 15:24:19 GMT","from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 66C384C040;\n\tTue, 5 Sep 2017 16:21:03 +0100 (BST)","from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 18C0B4C046;\n\tTue, 5 Sep 2017 16:21:03 +0100 (BST)","from oc3836556865.ibm.com (unknown [9.152.224.207])\n\tby d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP;\n\tTue, 5 Sep 2017 16:21:03 +0100 (BST)"],"To":"Cornelia Huck ","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-3-pasic@linux.vnet.ibm.com>\n\t<20170831111953.242ddc28.cohuck@redhat.com>\n\t\n\t<20170905100234.7a92128e.cohuck@redhat.com>","From":"Halil Pasic ","Date":"Tue, 5 Sep 2017 17:24:19 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.0","MIME-Version":"1.0","In-Reply-To":"<20170905100234.7a92128e.cohuck@redhat.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","X-TM-AS-GCONF":"00","x-cbid":"17090515-0040-0000-0000-000003F5C23F","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17090515-0041-0000-0000-0000209639BF","Message-Id":"","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-05_07:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709050219","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 2/9] s390x: fix invalid use of cc 1 for SSCH","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Dong Jia Shi ,\n\tPierre Morel , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1763457,"web_url":"http://patchwork.ozlabs.org/comment/1763457/","msgid":"<20170905174606.1e0c6404.cohuck@redhat.com>","list_archive_url":null,"date":"2017-09-05T15:46:06","subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","submitter":{"id":71914,"url":"http://patchwork.ozlabs.org/api/people/71914/","name":"Cornelia Huck","email":"cohuck@redhat.com"},"content":"On Tue, 5 Sep 2017 17:24:19 +0200\nHalil Pasic wrote:\n\n> My problem with a program check (indicated by SCSW word 2 bit 10) is\n> that, in my reading of the architecture, the semantic behind it is: The\n> channel subsystem (not the cu or device) has detected, that the \n> the channel program (previously submitted as an ORB) is erroneous. Which\n> programs are erroneous is specified by the architecture. What we have\n> here does not qualify.\n> \n> My idea was to rather blame the virtual hardware (device) and put no blame\n> on the program nor he channel subsystem. This could be done using device\n> status (unit check with command reject, maybe unit exception) or interface\n> check. My train of thought was, the problem is not consistent across a\n> device type, so it has to be device specific.\n\nUnit exception might be a better way to express what is happening here.\nAt least, it moves us away from cc 1 and not towards cc 3 :)\n\n> \n> Of course blaming the device could mislead the person encountering the\n> problem, and make him believe it's an non-virtual hardware problem.\n> \n> About the misleading, I think the best we can do is log out a message\n> indicating what really happened.\n\nJust document it in the code? If it doesn't happen with Linux as a\nguest, it is highly unlikely to be seen in the wild.\n\n> \n> In the end I don't care that deeply about vfio-ccw, and this problem\n> already took me more time than I intended to spend on this. We have\n> people driving this whole vfio-ccw stuff and I'm not one of them (I'm\n> rather in the supporting role).\n> \n> I'm also fine with me being credited with a reported-by once the\n> more involved people figure out what to do, and keeping the vfio-ccw\n> stuff as is. Should we go with that option? \n\nIf converting the reporting to a device status is straightforward\nenough, let's do that. I'm fine with postponing this and waiting for a\nreal fix as well (I don't really have spare cycles to actually write\nvfio-ccw code currently...)\n\n> >>>> @@ -1115,7 +1112,7 @@ static int do_subchannel_work(SubchDev *sch)\n> >>>> if (sch->do_subchannel_work) {\n> >>>> return sch->do_subchannel_work(sch);\n> >>>> } else {\n> >>>> - return -EINVAL;\n> >>>> + return -ENODEV; \n> >>>\n> >>> This rather seems like a job for an assert? If we don't have a function\n> >>> for the 'asynchronous' handling of the various functions assigned for a\n> >>> subchannel, that looks like an internal error.\n> >>> \n> >>\n> >> IMHO it depends. Aborting qemu is heavy handed, and as an user I would not\n> >> be happy about it. But certainly it is an assert situation. We can look for\n> >> an even better solution, but I think this is an improvement. The logic behind\n> >> is that the device is broken and can't be talked to properly. \n> > \n> > We currently don't have a vast array of subchannel types (and are\n> > unlikely to get more types that need a different handler function). We\n> > know the current ones are fine, and an assert would catch programming\n> > errors early.\n> > \n> \n> Despite of that we already had a problem of this type: see 1728cff2ab\n> (\"s390x/3270: fix instruction interception handler\", 2017-06-09) by \n> Dong Jia. If we had some automated testing covering all the asserts\n> I would not think twice about using an assert here. But I don't think\n> we do and I'm reluctant (not positive that assert is superior to what\n> we have now). Maybe we could agree on reported by again.\n\nYes, we (as in generally 'we') are really lacking automated testing...\n(it is somewhere on my todo list).\n\nEither leave it as-is, or do an assert. -ENODEV just feels wrong.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx04.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx04.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=cohuck@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xmrgM2P0Wz9sP3\n\tfor ;\n\tWed, 6 Sep 2017 01:46:54 +1000 (AEST)","from localhost ([::1]:59731 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpG3v-0005ah-Gk\n\tfor incoming@patchwork.ozlabs.org; Tue, 05 Sep 2017 11:46:51 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:56004)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpG3P-0005Yk-BK\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 11:46:24 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpG3H-0005jG-Ix\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 11:46:19 -0400","from mx1.redhat.com ([209.132.183.28]:54738)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dpG3H-0005ib-Au\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 11:46:11 -0400","from smtp.corp.redhat.com\n\t(int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 0747C10DAE;\n\tTue, 5 Sep 2017 15:46:10 +0000 (UTC)","from gondolin (dhcp-192-215.str.redhat.com [10.33.192.215])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id F0CF161B60;\n\tTue, 5 Sep 2017 15:46:08 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 0747C10DAE","Date":"Tue, 5 Sep 2017 17:46:06 +0200","From":"Cornelia Huck ","To":"Halil Pasic ","Message-ID":"<20170905174606.1e0c6404.cohuck@redhat.com>","In-Reply-To":"","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-3-pasic@linux.vnet.ibm.com>\n\t<20170831111953.242ddc28.cohuck@redhat.com>\n\t\n\t<20170905100234.7a92128e.cohuck@redhat.com>\n\t","Organization":"Red Hat GmbH","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.14","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.28]);\n\tTue, 05 Sep 2017 15:46:10 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Dong Jia Shi ,\n\tPierre Morel , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1763522,"web_url":"http://patchwork.ozlabs.org/comment/1763522/","msgid":"<24e87c3e-2674-8fc1-cd0a-94f4907ddc7d@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-05T17:20:43","subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","submitter":{"id":68297,"url":"http://patchwork.ozlabs.org/api/people/68297/","name":"Halil Pasic","email":"pasic@linux.vnet.ibm.com"},"content":"On 09/05/2017 05:46 PM, Cornelia Huck wrote:\n> On Tue, 5 Sep 2017 17:24:19 +0200\n> Halil Pasic wrote:\n> \n>> My problem with a program check (indicated by SCSW word 2 bit 10) is\n>> that, in my reading of the architecture, the semantic behind it is: The\n>> channel subsystem (not the cu or device) has detected, that the \n>> the channel program (previously submitted as an ORB) is erroneous. Which\n>> programs are erroneous is specified by the architecture. What we have\n>> here does not qualify.\n>>\n>> My idea was to rather blame the virtual hardware (device) and put no blame\n>> on the program nor he channel subsystem. This could be done using device\n>> status (unit check with command reject, maybe unit exception) or interface\n>> check. My train of thought was, the problem is not consistent across a\n>> device type, so it has to be device specific.\n> \n> Unit exception might be a better way to express what is happening here.\n> At least, it moves us away from cc 1 and not towards cc 3 :)\n> \n\nI will do a follow up patch pursuing device exception.\n\n>>\n>> Of course blaming the device could mislead the person encountering the\n>> problem, and make him believe it's an non-virtual hardware problem.\n>>\n>> About the misleading, I think the best we can do is log out a message\n>> indicating what really happened.\n> \n> Just document it in the code? If it doesn't happen with Linux as a\n> guest, it is highly unlikely to be seen in the wild.\n> \n\n\nWell we have two problems here:\n1) Unit exception can be already defined by the device type for the\ncommand (reference: http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/dz9ar110/2.6.10?DT=19920904110920).\nI think this one is what you mean. And I agree that's best handled\nwith comment in code.\n2) The poor user/programmer is trying to figure out why things\ndon't work (why are we getting the unit exception)? I think that's\nbest remedied with producing something for the log (maybe a warning\nwith warn_report which states that the implementation vfio-ccw requires\nthe given flags).\n\n[..] \n>>>>>> @@ -1115,7 +1112,7 @@ static int do_subchannel_work(SubchDev *sch)\n>>>>>> if (sch->do_subchannel_work) {\n>>>>>> return sch->do_subchannel_work(sch);\n>>>>>> } else {\n>>>>>> - return -EINVAL;\n>>>>>> + return -ENODEV; \n>>>>>\n>>>>> This rather seems like a job for an assert? If we don't have a function\n>>>>> for the 'asynchronous' handling of the various functions assigned for a\n>>>>> subchannel, that looks like an internal error.\n>>>>> \n>>>>\n>>>> IMHO it depends. Aborting qemu is heavy handed, and as an user I would not\n>>>> be happy about it. But certainly it is an assert situation. We can look for\n>>>> an even better solution, but I think this is an improvement. The logic behind\n>>>> is that the device is broken and can't be talked to properly. \n>>>\n>>> We currently don't have a vast array of subchannel types (and are\n>>> unlikely to get more types that need a different handler function). We\n>>> know the current ones are fine, and an assert would catch programming\n>>> errors early.\n>>> \n>>\n>> Despite of that we already had a problem of this type: see 1728cff2ab\n>> (\"s390x/3270: fix instruction interception handler\", 2017-06-09) by \n>> Dong Jia. If we had some automated testing covering all the asserts\n>> I would not think twice about using an assert here. But I don't think\n>> we do and I'm reluctant (not positive that assert is superior to what\n>> we have now). Maybe we could agree on reported by again.\n> \n> Yes, we (as in generally 'we') are really lacking automated testing...\n> (it is somewhere on my todo list).\n> \n> Either leave it as-is, or do an assert. -ENODEV just feels wrong.\n> \n\nI think I will leave this one as is and maybe try to discuss with\nthe folks here about reliable test coverage. Just spoke with Marc H.,\nand according to that we have a long way to go.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xmtmM5cSCz9sNq\n\tfor ;\n\tWed, 6 Sep 2017 03:21:23 +1000 (AEST)","from localhost ([::1]:60309 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpHXN-0007Hi-NK\n\tfor incoming@patchwork.ozlabs.org; Tue, 05 Sep 2017 13:21:21 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:46682)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpHWx-0007Fn-PX\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 13:21:00 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpHWs-00075z-L6\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 13:20:55 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:41468)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dpHWs-000759-Bd\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 13:20:50 -0400","from pps.filterd (m0098393.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv85HJpix040429\n\tfor ; Tue, 5 Sep 2017 13:20:49 -0400","from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2csyqvsfs3-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Tue, 05 Sep 2017 13:20:48 -0400","from localhost\n\tby e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tTue, 5 Sep 2017 18:20:46 +0100","from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195)\n\tby e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tTue, 5 Sep 2017 18:20:44 +0100","from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com\n\t[9.149.105.58])\n\tby b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v85HKiKI28770468; Tue, 5 Sep 2017 17:20:44 GMT","from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id F2AA74C050;\n\tTue, 5 Sep 2017 18:17:27 +0100 (BST)","from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id B33DE4C04A;\n\tTue, 5 Sep 2017 18:17:27 +0100 (BST)","from oc3836556865.ibm.com (unknown [9.152.224.207])\n\tby d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP;\n\tTue, 5 Sep 2017 18:17:27 +0100 (BST)"],"To":"Cornelia Huck ","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-3-pasic@linux.vnet.ibm.com>\n\t<20170831111953.242ddc28.cohuck@redhat.com>\n\t\n\t<20170905100234.7a92128e.cohuck@redhat.com>\n\t\n\t<20170905174606.1e0c6404.cohuck@redhat.com>","From":"Halil Pasic ","Date":"Tue, 5 Sep 2017 19:20:43 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.0","MIME-Version":"1.0","In-Reply-To":"<20170905174606.1e0c6404.cohuck@redhat.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","X-TM-AS-GCONF":"00","x-cbid":"17090517-0020-0000-0000-000003B3CABE","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17090517-0021-0000-0000-000042443526","Message-Id":"<24e87c3e-2674-8fc1-cd0a-94f4907ddc7d@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-05_07:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709050250","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 2/9] s390x: fix invalid use of cc 1 for SSCH","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Dong Jia Shi ,\n\tPierre Morel , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1763912,"web_url":"http://patchwork.ozlabs.org/comment/1763912/","msgid":"<20170906082720.GZ31680@bjsdjshi@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-06T08:27:20","subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","submitter":{"id":68897,"url":"http://patchwork.ozlabs.org/api/people/68897/","name":"Dong Jia Shi","email":"bjsdjshi@linux.vnet.ibm.com"},"content":"* Halil Pasic [2017-09-05 19:20:43 +0200]:\n\n> \n> \n> On 09/05/2017 05:46 PM, Cornelia Huck wrote:\n> > On Tue, 5 Sep 2017 17:24:19 +0200\n> > Halil Pasic wrote:\n> > \n> >> My problem with a program check (indicated by SCSW word 2 bit 10) is\n> >> that, in my reading of the architecture, the semantic behind it is: The\n> >> channel subsystem (not the cu or device) has detected, that the \n> >> the channel program (previously submitted as an ORB) is erroneous. Which\n> >> programs are erroneous is specified by the architecture. What we have\n> >> here does not qualify.\n> >>\n> >> My idea was to rather blame the virtual hardware (device) and put no blame\n> >> on the program nor he channel subsystem. This could be done using device\n> >> status (unit check with command reject, maybe unit exception) or interface\n> >> check. My train of thought was, the problem is not consistent across a\n> >> device type, so it has to be device specific.\n> > \n> > Unit exception might be a better way to express what is happening here.\n> > At least, it moves us away from cc 1 and not towards cc 3 :)\n> > \n> \n> I will do a follow up patch pursuing device exception.\n> \n> >>\n> >> Of course blaming the device could mislead the person encountering the\n> >> problem, and make him believe it's an non-virtual hardware problem.\n> >>\n> >> About the misleading, I think the best we can do is log out a message\n> >> indicating what really happened.\n> > \n> > Just document it in the code? If it doesn't happen with Linux as a\n> > guest, it is highly unlikely to be seen in the wild.\n> > \n> \n> \n> Well we have two problems here:\n> 1) Unit exception can be already defined by the device type for the\n> command (reference: http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/dz9ar110/2.6.10?DT=19920904110920).\n> I think this one is what you mean. And I agree that's best handled\n> with comment in code.\nUsing unit check, with bit 3 byte 0 of the sense data set to 1, to\nindicate an 'Equipment check', sounds a bit more proper than unit\nexception.\n\n> 2) The poor user/programmer is trying to figure out why things\n> don't work (why are we getting the unit exception)? I think that's\n> best remedied with producing something for the log (maybe a warning\n> with warn_report which states that the implementation vfio-ccw requires\n> the given flags).\nFine with me.\n\n[...]","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xnGth3BCQz9s9Y\n\tfor ;\n\tWed, 6 Sep 2017 18:28:12 +1000 (AEST)","from localhost ([::1]:34941 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpVgw-0007Jg-I0\n\tfor incoming@patchwork.ozlabs.org; Wed, 06 Sep 2017 04:28:10 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:47845)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpVgJ-0007HY-RL\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 04:27:33 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpVgF-0002Zk-Pu\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 04:27:31 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:58544)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dpVgF-0002Z4-GX\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 04:27:27 -0400","from pps.filterd (m0098393.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv868QF0H136452\n\tfor ; Wed, 6 Sep 2017 04:27:26 -0400","from e18.ny.us.ibm.com (e18.ny.us.ibm.com [129.33.205.208])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2ct76an3tg-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Wed, 06 Sep 2017 04:27:25 -0400","from localhost\n\tby e18.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tWed, 6 Sep 2017 04:27:24 -0400","from b01cxnp23033.gho.pok.ibm.com (9.57.198.28)\n\tby e18.ny.us.ibm.com (146.89.104.205) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tWed, 6 Sep 2017 04:27:22 -0400","from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com\n\t[9.57.199.110])\n\tby b01cxnp23033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP\n\tid v868RM9V59048100; Wed, 6 Sep 2017 08:27:22 GMT","from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id E88A2AE03B;\n\tWed, 6 Sep 2017 04:27:48 -0400 (EDT)","from localhost (unknown [9.115.112.23])\n\tby b01ledav005.gho.pok.ibm.com (Postfix) with ESMTP id 279D6AE034;\n\tWed, 6 Sep 2017 04:27:47 -0400 (EDT)"],"Date":"Wed, 6 Sep 2017 16:27:20 +0800","From":"Dong Jia Shi ","To":"Halil Pasic ","Mail-Followup-To":"Halil Pasic ,\n\tCornelia Huck ,\n\tDong Jia Shi ,\n\tPierre Morel , qemu-devel@nongnu.org","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-3-pasic@linux.vnet.ibm.com>\n\t<20170831111953.242ddc28.cohuck@redhat.com>\n\t\n\t<20170905100234.7a92128e.cohuck@redhat.com>\n\t\n\t<20170905174606.1e0c6404.cohuck@redhat.com>\n\t<24e87c3e-2674-8fc1-cd0a-94f4907ddc7d@linux.vnet.ibm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<24e87c3e-2674-8fc1-cd0a-94f4907ddc7d@linux.vnet.ibm.com>","Organization":"(IBM CSL)","X-URL":"http://ibm.com/","User-Agent":"Mutt/1.5.21 (2010-09-15)","X-TM-AS-GCONF":"00","x-cbid":"17090608-0044-0000-0000-00000388A222","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007676; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000226; SDB=6.00912986; UDB=6.00458182;\n\tIPR=6.00693248; \n\tBA=6.00005573; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009;\n\tZB=6.00000000; \n\tZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017028;\n\tXFM=3.00000015; UTC=2017-09-06 08:27:23","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17090608-0045-0000-0000-000007B6BD50","Message-Id":"<20170906082720.GZ31680@bjsdjshi@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-06_02:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709060115","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 2/9] s390x: fix invalid use of cc 1 for SSCH","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Dong Jia Shi ,\n\tCornelia Huck ,\n\tPierre Morel , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1763915,"web_url":"http://patchwork.ozlabs.org/comment/1763915/","msgid":"<20170906083708.GA31680@bjsdjshi@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-06T08:37:08","subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","submitter":{"id":68897,"url":"http://patchwork.ozlabs.org/api/people/68897/","name":"Dong Jia Shi","email":"bjsdjshi@linux.vnet.ibm.com"},"content":"* Cornelia Huck [2017-09-05 17:46:06 +0200]:\n\n> On Tue, 5 Sep 2017 17:24:19 +0200\n> Halil Pasic wrote:\n> \n> > My problem with a program check (indicated by SCSW word 2 bit 10) is\n> > that, in my reading of the architecture, the semantic behind it is: The\n> > channel subsystem (not the cu or device) has detected, that the \n> > the channel program (previously submitted as an ORB) is erroneous. Which\n> > programs are erroneous is specified by the architecture. What we have\n> > here does not qualify.\n> > \n> > My idea was to rather blame the virtual hardware (device) and put no blame\n> > on the program nor he channel subsystem. This could be done using device\n> > status (unit check with command reject, maybe unit exception) or interface\n> > check. My train of thought was, the problem is not consistent across a\n> > device type, so it has to be device specific.\n> \n> Unit exception might be a better way to express what is happening here.\n> At least, it moves us away from cc 1 and not towards cc 3 :)\n> \n> > \n> > Of course blaming the device could mislead the person encountering the\n> > problem, and make him believe it's an non-virtual hardware problem.\n> > \n> > About the misleading, I think the best we can do is log out a message\n> > indicating what really happened.\n> \n> Just document it in the code? If it doesn't happen with Linux as a\n> guest, it is highly unlikely to be seen in the wild.\n> \n> > \n> > In the end I don't care that deeply about vfio-ccw, and this problem\n> > already took me more time than I intended to spend on this. We have\n> > people driving this whole vfio-ccw stuff and I'm not one of them (I'm\n> > rather in the supporting role).\n> > \n> > I'm also fine with me being credited with a reported-by once the\n> > more involved people figure out what to do, and keeping the vfio-ccw\n> > stuff as is. Should we go with that option? \n> \n> If converting the reporting to a device status is straightforward\n> enough, let's do that. I'm fine with postponing this and waiting for a\n> real fix as well (I don't really have spare cycles to actually write\n> vfio-ccw code currently...)\n> \n\nI can do this after this series.\n\n[...]","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xnH5g2x8sz9s9Y\n\tfor ;\n\tWed, 6 Sep 2017 18:37:43 +1000 (AEST)","from localhost ([::1]:34983 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpVq9-0002fb-Gv\n\tfor incoming@patchwork.ozlabs.org; Wed, 06 Sep 2017 04:37:41 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:51003)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpVpm-0002fB-BW\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 04:37:19 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpVpj-0007M7-3g\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 04:37:18 -0400","from mx0b-001b2d01.pphosted.com ([148.163.158.5]:53166\n\thelo=mx0a-001b2d01.pphosted.com)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dpVpi-0007Ly-UC\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 04:37:15 -0400","from pps.filterd (m0098421.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv868Tl38119836\n\tfor ; Wed, 6 Sep 2017 04:37:14 -0400","from e18.ny.us.ibm.com (e18.ny.us.ibm.com [129.33.205.208])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2ctd7ch95k-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Wed, 06 Sep 2017 04:37:14 -0400","from localhost\n\tby e18.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tWed, 6 Sep 2017 04:37:13 -0400","from b01cxnp22034.gho.pok.ibm.com (9.57.198.24)\n\tby e18.ny.us.ibm.com (146.89.104.205) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tWed, 6 Sep 2017 04:37:10 -0400","from b01ledav006.gho.pok.ibm.com (b01ledav006.gho.pok.ibm.com\n\t[9.57.199.111])\n\tby b01cxnp22034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP\n\tid v868bAkm23461972; Wed, 6 Sep 2017 08:37:10 GMT","from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 6D2D1AC03F;\n\tWed, 6 Sep 2017 04:37:37 -0400 (EDT)","from localhost (unknown [9.115.112.23])\n\tby b01ledav006.gho.pok.ibm.com (Postfix) with ESMTP id 9D197AC03A;\n\tWed, 6 Sep 2017 04:37:36 -0400 (EDT)"],"Date":"Wed, 6 Sep 2017 16:37:08 +0800","From":"Dong Jia Shi ","To":"Cornelia Huck ","Mail-Followup-To":"Cornelia Huck ,\n\tHalil Pasic ,\n\tDong Jia Shi ,\n\tPierre Morel , qemu-devel@nongnu.org","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-3-pasic@linux.vnet.ibm.com>\n\t<20170831111953.242ddc28.cohuck@redhat.com>\n\t\n\t<20170905100234.7a92128e.cohuck@redhat.com>\n\t\n\t<20170905174606.1e0c6404.cohuck@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170905174606.1e0c6404.cohuck@redhat.com>","Organization":"(IBM CSL)","X-URL":"http://ibm.com/","User-Agent":"Mutt/1.5.21 (2010-09-15)","X-TM-AS-GCONF":"00","x-cbid":"17090608-0044-0000-0000-00000388A2FA","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007676; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000226; SDB=6.00912990; UDB=6.00458184;\n\tIPR=6.00693252; \n\tBA=6.00005573; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009;\n\tZB=6.00000000; \n\tZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017028;\n\tXFM=3.00000015; UTC=2017-09-06 08:37:11","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17090608-0045-0000-0000-000007B6BE29","Message-Id":"<20170906083708.GA31680@bjsdjshi@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-06_02:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709060117","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy]","X-Received-From":"148.163.158.5","Subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Halil Pasic ,\n\tPierre Morel ,\n\tDong Jia Shi , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1764027,"web_url":"http://patchwork.ozlabs.org/comment/1764027/","msgid":"<20170906132538.73b31142.cohuck@redhat.com>","list_archive_url":null,"date":"2017-09-06T11:25:38","subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","submitter":{"id":71914,"url":"http://patchwork.ozlabs.org/api/people/71914/","name":"Cornelia Huck","email":"cohuck@redhat.com"},"content":"On Wed, 6 Sep 2017 16:27:20 +0800\nDong Jia Shi wrote:\n\n> * Halil Pasic [2017-09-05 19:20:43 +0200]:\n> \n> > \n> > \n> > On 09/05/2017 05:46 PM, Cornelia Huck wrote: \n> > > On Tue, 5 Sep 2017 17:24:19 +0200\n> > > Halil Pasic wrote:\n> > > \n> > >> My problem with a program check (indicated by SCSW word 2 bit 10) is\n> > >> that, in my reading of the architecture, the semantic behind it is: The\n> > >> channel subsystem (not the cu or device) has detected, that the \n> > >> the channel program (previously submitted as an ORB) is erroneous. Which\n> > >> programs are erroneous is specified by the architecture. What we have\n> > >> here does not qualify.\n> > >>\n> > >> My idea was to rather blame the virtual hardware (device) and put no blame\n> > >> on the program nor he channel subsystem. This could be done using device\n> > >> status (unit check with command reject, maybe unit exception) or interface\n> > >> check. My train of thought was, the problem is not consistent across a\n> > >> device type, so it has to be device specific. \n> > > \n> > > Unit exception might be a better way to express what is happening here.\n> > > At least, it moves us away from cc 1 and not towards cc 3 :)\n> > > \n> > \n> > I will do a follow up patch pursuing device exception.\n> > \n> > >>\n> > >> Of course blaming the device could mislead the person encountering the\n> > >> problem, and make him believe it's an non-virtual hardware problem.\n> > >>\n> > >> About the misleading, I think the best we can do is log out a message\n> > >> indicating what really happened. \n> > > \n> > > Just document it in the code? If it doesn't happen with Linux as a\n> > > guest, it is highly unlikely to be seen in the wild.\n> > > \n> > \n> > \n> > Well we have two problems here:\n> > 1) Unit exception can be already defined by the device type for the\n> > command (reference: http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/dz9ar110/2.6.10?DT=19920904110920).\n> > I think this one is what you mean. And I agree that's best handled\n> > with comment in code. \n> Using unit check, with bit 3 byte 0 of the sense data set to 1, to\n> indicate an 'Equipment check', sounds a bit more proper than unit\n> exception.\n\nI don't agree: Equipment check sounds a lot more dire (and seems to\nimply a malfunction). I like unit exception better.\n\n> \n> > 2) The poor user/programmer is trying to figure out why things\n> > don't work (why are we getting the unit exception)? I think that's\n> > best remedied with producing something for the log (maybe a warning\n> > with warn_report which states that the implementation vfio-ccw requires\n> > the given flags). \n> Fine with me.\n\nWith me as well.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx01.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx01.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=cohuck@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xnLtl5yMhz9s9Y\n\tfor ;\n\tWed, 6 Sep 2017 21:28:31 +1000 (AEST)","from localhost ([::1]:35492 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpYVR-00044S-VI\n\tfor incoming@patchwork.ozlabs.org; Wed, 06 Sep 2017 07:28:29 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:51772)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpYSp-0002JO-Fy\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 07:25:48 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpYSk-0005T4-HE\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 07:25:47 -0400","from mx1.redhat.com ([209.132.183.28]:52666)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dpYSk-0005SM-7y\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 07:25:42 -0400","from smtp.corp.redhat.com\n\t(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 4CA1885376;\n\tWed, 6 Sep 2017 11:25:41 +0000 (UTC)","from gondolin (dhcp-192-215.str.redhat.com [10.33.192.215])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 896C419E97;\n\tWed, 6 Sep 2017 11:25:40 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 4CA1885376","Date":"Wed, 6 Sep 2017 13:25:38 +0200","From":"Cornelia Huck ","To":"Dong Jia Shi ","Message-ID":"<20170906132538.73b31142.cohuck@redhat.com>","In-Reply-To":"<20170906082720.GZ31680@bjsdjshi@linux.vnet.ibm.com>","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-3-pasic@linux.vnet.ibm.com>\n\t<20170831111953.242ddc28.cohuck@redhat.com>\n\t\n\t<20170905100234.7a92128e.cohuck@redhat.com>\n\t\n\t<20170905174606.1e0c6404.cohuck@redhat.com>\n\t<24e87c3e-2674-8fc1-cd0a-94f4907ddc7d@linux.vnet.ibm.com>\n\t<20170906082720.GZ31680@bjsdjshi@linux.vnet.ibm.com>","Organization":"Red Hat GmbH","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.11","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.25]);\n\tWed, 06 Sep 2017 11:25:41 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Halil Pasic ,\n\tPierre Morel , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1764038,"web_url":"http://patchwork.ozlabs.org/comment/1764038/","msgid":"<20170906133709.6072a661.cohuck@redhat.com>","list_archive_url":null,"date":"2017-09-06T11:37:09","subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","submitter":{"id":71914,"url":"http://patchwork.ozlabs.org/api/people/71914/","name":"Cornelia Huck","email":"cohuck@redhat.com"},"content":"On Tue, 5 Sep 2017 19:20:43 +0200\nHalil Pasic wrote:\n\n> On 09/05/2017 05:46 PM, Cornelia Huck wrote:\n> > On Tue, 5 Sep 2017 17:24:19 +0200\n> > Halil Pasic wrote:\n\n> >> Despite of that we already had a problem of this type: see 1728cff2ab\n> >> (\"s390x/3270: fix instruction interception handler\", 2017-06-09) by \n> >> Dong Jia. If we had some automated testing covering all the asserts\n> >> I would not think twice about using an assert here. But I don't think\n> >> we do and I'm reluctant (not positive that assert is superior to what\n> >> we have now). Maybe we could agree on reported by again. \n> > \n> > Yes, we (as in generally 'we') are really lacking automated testing...\n> > (it is somewhere on my todo list).\n> > \n> > Either leave it as-is, or do an assert. -ENODEV just feels wrong.\n> > \n> \n> I think I will leave this one as is and maybe try to discuss with\n> the folks here about reliable test coverage. Just spoke with Marc H.,\n> and according to that we have a long way to go.\n\nIdeally, we want something that can be executed from 'make check'. We\ncan already cover some basic stuff via tcg (I need to look into wiring\nup more stuff), people with access to hardware should be able to cover\nthe rest.\n\nThat's not to say that extensive in-house testing by you guys wouldn't\nbe helpful, quite the contrary :)","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx05.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx05.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=cohuck@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xnM5h1BMGz9s9Y\n\tfor ;\n\tWed, 6 Sep 2017 21:38:00 +1000 (AEST)","from localhost ([::1]:35517 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpYec-0000AR-7y\n\tfor incoming@patchwork.ozlabs.org; Wed, 06 Sep 2017 07:37:58 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:55390)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpYdx-00005y-Ee\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 07:37:22 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpYdt-0001zT-Io\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 07:37:17 -0400","from mx1.redhat.com ([209.132.183.28]:45208)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dpYdt-0001zD-DO\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 07:37:13 -0400","from smtp.corp.redhat.com\n\t(int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 76FFC37EE9;\n\tWed, 6 Sep 2017 11:37:12 +0000 (UTC)","from gondolin (dhcp-192-215.str.redhat.com [10.33.192.215])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 6D0C15C8AF;\n\tWed, 6 Sep 2017 11:37:11 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 76FFC37EE9","Date":"Wed, 6 Sep 2017 13:37:09 +0200","From":"Cornelia Huck ","To":"Halil Pasic ","Message-ID":"<20170906133709.6072a661.cohuck@redhat.com>","In-Reply-To":"<24e87c3e-2674-8fc1-cd0a-94f4907ddc7d@linux.vnet.ibm.com>","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-3-pasic@linux.vnet.ibm.com>\n\t<20170831111953.242ddc28.cohuck@redhat.com>\n\t\n\t<20170905100234.7a92128e.cohuck@redhat.com>\n\t\n\t<20170905174606.1e0c6404.cohuck@redhat.com>\n\t<24e87c3e-2674-8fc1-cd0a-94f4907ddc7d@linux.vnet.ibm.com>","Organization":"Red Hat GmbH","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.16","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.29]);\n\tWed, 06 Sep 2017 11:37:12 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Thomas Huth ,\n\tDong Jia Shi , \n\tPierre Morel , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1764039,"web_url":"http://patchwork.ozlabs.org/comment/1764039/","msgid":"<20170906133817.344972d1.cohuck@redhat.com>","list_archive_url":null,"date":"2017-09-06T11:38:17","subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","submitter":{"id":71914,"url":"http://patchwork.ozlabs.org/api/people/71914/","name":"Cornelia Huck","email":"cohuck@redhat.com"},"content":"On Wed, 6 Sep 2017 16:37:08 +0800\nDong Jia Shi wrote:\n\n> * Cornelia Huck [2017-09-05 17:46:06 +0200]:\n> \n> > On Tue, 5 Sep 2017 17:24:19 +0200\n> > Halil Pasic wrote:\n\n> > > In the end I don't care that deeply about vfio-ccw, and this problem\n> > > already took me more time than I intended to spend on this. We have\n> > > people driving this whole vfio-ccw stuff and I'm not one of them (I'm\n> > > rather in the supporting role).\n> > > \n> > > I'm also fine with me being credited with a reported-by once the\n> > > more involved people figure out what to do, and keeping the vfio-ccw\n> > > stuff as is. Should we go with that option? \n> > \n> > If converting the reporting to a device status is straightforward\n> > enough, let's do that. I'm fine with postponing this and waiting for a\n> > real fix as well (I don't really have spare cycles to actually write\n> > vfio-ccw code currently...)\n> > \n> \n> I can do this after this series.\n\nCool, thanks!","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx01.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx01.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=cohuck@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xnM6q0QdFz9s9Y\n\tfor ;\n\tWed, 6 Sep 2017 21:38:59 +1000 (AEST)","from localhost ([::1]:35520 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpYfZ-0000yk-2p\n\tfor incoming@patchwork.ozlabs.org; Wed, 06 Sep 2017 07:38:57 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:55788)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpYf2-0000wn-KC\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 07:38:25 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpYez-0002MD-Hx\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 07:38:24 -0400","from mx1.redhat.com ([209.132.183.28]:36606)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dpYez-0002Lx-Bf\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 07:38:21 -0400","from smtp.corp.redhat.com\n\t(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 6647981DFE;\n\tWed, 6 Sep 2017 11:38:20 +0000 (UTC)","from gondolin (dhcp-192-215.str.redhat.com [10.33.192.215])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id A180F1880E;\n\tWed, 6 Sep 2017 11:38:19 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 6647981DFE","Date":"Wed, 6 Sep 2017 13:38:17 +0200","From":"Cornelia Huck ","To":"Dong Jia Shi ","Message-ID":"<20170906133817.344972d1.cohuck@redhat.com>","In-Reply-To":"<20170906083708.GA31680@bjsdjshi@linux.vnet.ibm.com>","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-3-pasic@linux.vnet.ibm.com>\n\t<20170831111953.242ddc28.cohuck@redhat.com>\n\t\n\t<20170905100234.7a92128e.cohuck@redhat.com>\n\t\n\t<20170905174606.1e0c6404.cohuck@redhat.com>\n\t<20170906083708.GA31680@bjsdjshi@linux.vnet.ibm.com>","Organization":"Red Hat GmbH","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.12","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.25]);\n\tWed, 06 Sep 2017 11:38:20 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Halil Pasic ,\n\tPierre Morel , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1764572,"web_url":"http://patchwork.ozlabs.org/comment/1764572/","msgid":"<20170907080208.GE31680@bjsdjshi@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-07T08:02:08","subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","submitter":{"id":68897,"url":"http://patchwork.ozlabs.org/api/people/68897/","name":"Dong Jia Shi","email":"bjsdjshi@linux.vnet.ibm.com"},"content":"* Cornelia Huck [2017-09-06 13:25:38 +0200]:\n\n> On Wed, 6 Sep 2017 16:27:20 +0800\n> Dong Jia Shi wrote:\n> \n> > * Halil Pasic [2017-09-05 19:20:43 +0200]:\n> > \n> > > \n> > > \n> > > On 09/05/2017 05:46 PM, Cornelia Huck wrote: \n> > > > On Tue, 5 Sep 2017 17:24:19 +0200\n> > > > Halil Pasic wrote:\n> > > > \n> > > >> My problem with a program check (indicated by SCSW word 2 bit 10) is\n> > > >> that, in my reading of the architecture, the semantic behind it is: The\n> > > >> channel subsystem (not the cu or device) has detected, that the \n> > > >> the channel program (previously submitted as an ORB) is erroneous. Which\n> > > >> programs are erroneous is specified by the architecture. What we have\n> > > >> here does not qualify.\n> > > >>\n> > > >> My idea was to rather blame the virtual hardware (device) and put no blame\n> > > >> on the program nor he channel subsystem. This could be done using device\n> > > >> status (unit check with command reject, maybe unit exception) or interface\n> > > >> check. My train of thought was, the problem is not consistent across a\n> > > >> device type, so it has to be device specific. \n> > > > \n> > > > Unit exception might be a better way to express what is happening here.\n> > > > At least, it moves us away from cc 1 and not towards cc 3 :)\n> > > > \n> > > \n> > > I will do a follow up patch pursuing device exception.\n> > > \n> > > >>\n> > > >> Of course blaming the device could mislead the person encountering the\n> > > >> problem, and make him believe it's an non-virtual hardware problem.\n> > > >>\n> > > >> About the misleading, I think the best we can do is log out a message\n> > > >> indicating what really happened. \n> > > > \n> > > > Just document it in the code? If it doesn't happen with Linux as a\n> > > > guest, it is highly unlikely to be seen in the wild.\n> > > > \n> > > \n> > > \n> > > Well we have two problems here:\n> > > 1) Unit exception can be already defined by the device type for the\n> > > command (reference: http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/dz9ar110/2.6.10?DT=19920904110920).\n> > > I think this one is what you mean. And I agree that's best handled\n> > > with comment in code. \n> > Using unit check, with bit 3 byte 0 of the sense data set to 1, to\n> > indicate an 'Equipment check', sounds a bit more proper than unit\n> > exception.\n> \n> I don't agree: Equipment check sounds a lot more dire (and seems to\n> imply a malfunction). I like unit exception better.\nGot the point. Fair enough!","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xntH44mXpz9sRY\n\tfor ;\n\tThu, 7 Sep 2017 18:02:55 +1000 (AEST)","from localhost ([::1]:39197 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dprm0-0002Ob-19\n\tfor incoming@patchwork.ozlabs.org; Thu, 07 Sep 2017 04:02:52 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:52994)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dprlV-0002Ld-FX\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 04:02:27 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dprlQ-00075X-Fn\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 04:02:21 -0400","from mx0b-001b2d01.pphosted.com ([148.163.158.5]:52109\n\thelo=mx0a-001b2d01.pphosted.com)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dprlQ-000752-9g\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 04:02:16 -0400","from pps.filterd (m0098420.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv877xSxp036836\n\tfor ; Thu, 7 Sep 2017 04:02:15 -0400","from e18.ny.us.ibm.com (e18.ny.us.ibm.com [129.33.205.208])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2cu10wbaph-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Thu, 07 Sep 2017 04:02:14 -0400","from localhost\n\tby e18.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tThu, 7 Sep 2017 04:02:13 -0400","from b01cxnp23033.gho.pok.ibm.com (9.57.198.28)\n\tby e18.ny.us.ibm.com (146.89.104.205) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tThu, 7 Sep 2017 04:02:11 -0400","from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com\n\t[9.57.199.109])\n\tby b01cxnp23033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP\n\tid v8782A3H64225392; Thu, 7 Sep 2017 08:02:10 GMT","from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id B5658112047;\n\tThu, 7 Sep 2017 04:01:54 -0400 (EDT)","from localhost (unknown [9.115.112.23])\n\tby b01ledav004.gho.pok.ibm.com (Postfix) with ESMTP id 0C806112034;\n\tThu, 7 Sep 2017 04:01:53 -0400 (EDT)"],"Date":"Thu, 7 Sep 2017 16:02:08 +0800","From":"Dong Jia Shi ","To":"Cornelia Huck ","Mail-Followup-To":"Cornelia Huck ,\n\tDong Jia Shi ,\n\tHalil Pasic ,\n\tPierre Morel , qemu-devel@nongnu.org","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-3-pasic@linux.vnet.ibm.com>\n\t<20170831111953.242ddc28.cohuck@redhat.com>\n\t\n\t<20170905100234.7a92128e.cohuck@redhat.com>\n\t\n\t<20170905174606.1e0c6404.cohuck@redhat.com>\n\t<24e87c3e-2674-8fc1-cd0a-94f4907ddc7d@linux.vnet.ibm.com>\n\t<20170906082720.GZ31680@bjsdjshi@linux.vnet.ibm.com>\n\t<20170906132538.73b31142.cohuck@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170906132538.73b31142.cohuck@redhat.com>","Organization":"(IBM CSL)","X-URL":"http://ibm.com/","User-Agent":"Mutt/1.5.21 (2010-09-15)","X-TM-AS-GCONF":"00","x-cbid":"17090708-0044-0000-0000-0000038A9939","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007681; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000226; SDB=6.00913458; UDB=6.00458464;\n\tIPR=6.00693716; \n\tBA=6.00005574; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009;\n\tZB=6.00000000; \n\tZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017046;\n\tXFM=3.00000015; UTC=2017-09-07 08:02:12","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17090708-0045-0000-0000-000007B9994E","Message-Id":"<20170907080208.GE31680@bjsdjshi@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-07_05:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709070117","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy]","X-Received-From":"148.163.158.5","Subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Dong Jia Shi ,\n\tPierre Morel ,\n\tHalil Pasic , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1764648,"web_url":"http://patchwork.ozlabs.org/comment/1764648/","msgid":"","list_archive_url":null,"date":"2017-09-07T11:01:34","subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","submitter":{"id":68297,"url":"http://patchwork.ozlabs.org/api/people/68297/","name":"Halil Pasic","email":"pasic@linux.vnet.ibm.com"},"content":"On 09/07/2017 10:02 AM, Dong Jia Shi wrote:\n> * Cornelia Huck [2017-09-06 13:25:38 +0200]:\n> \n>> On Wed, 6 Sep 2017 16:27:20 +0800\n>> Dong Jia Shi wrote:\n>>\n>>> * Halil Pasic [2017-09-05 19:20:43 +0200]:\n>>>\n>>>>\n>>>>\n>>>> On 09/05/2017 05:46 PM, Cornelia Huck wrote: \n>>>>> On Tue, 5 Sep 2017 17:24:19 +0200\n>>>>> Halil Pasic wrote:\n>>>>> \n>>>>>> My problem with a program check (indicated by SCSW word 2 bit 10) is\n>>>>>> that, in my reading of the architecture, the semantic behind it is: The\n>>>>>> channel subsystem (not the cu or device) has detected, that the \n>>>>>> the channel program (previously submitted as an ORB) is erroneous. Which\n>>>>>> programs are erroneous is specified by the architecture. What we have\n>>>>>> here does not qualify.\n>>>>>>\n>>>>>> My idea was to rather blame the virtual hardware (device) and put no blame\n>>>>>> on the program nor he channel subsystem. This could be done using device\n>>>>>> status (unit check with command reject, maybe unit exception) or interface\n>>>>>> check. My train of thought was, the problem is not consistent across a\n>>>>>> device type, so it has to be device specific. \n>>>>>\n>>>>> Unit exception might be a better way to express what is happening here.\n>>>>> At least, it moves us away from cc 1 and not towards cc 3 :)\n>>>>> \n>>>>\n>>>> I will do a follow up patch pursuing device exception.\n>>>> \n>>>>>>\n>>>>>> Of course blaming the device could mislead the person encountering the\n>>>>>> problem, and make him believe it's an non-virtual hardware problem.\n>>>>>>\n>>>>>> About the misleading, I think the best we can do is log out a message\n>>>>>> indicating what really happened. \n>>>>>\n>>>>> Just document it in the code? If it doesn't happen with Linux as a\n>>>>> guest, it is highly unlikely to be seen in the wild.\n>>>>> \n>>>>\n>>>>\n>>>> Well we have two problems here:\n>>>> 1) Unit exception can be already defined by the device type for the\n>>>> command (reference: http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/dz9ar110/2.6.10?DT=19920904110920).\n>>>> I think this one is what you mean. And I agree that's best handled\n>>>> with comment in code. \n>>> Using unit check, with bit 3 byte 0 of the sense data set to 1, to\n>>> indicate an 'Equipment check', sounds a bit more proper than unit\n>>> exception.\n>>\n>> I don't agree: Equipment check sounds a lot more dire (and seems to\n>> imply a malfunction). I like unit exception better.\n> Got the point. Fair enough!\n> \n\nI do see some benefit in doing unit check over unit exception. Just\nkept quite to see the discussion unfold. As already said, unit exception\nseems to be something reserved for the device type to define in a more\nor less arbitrary but unambiguous way. I agreed to use this, because\nI trust Connie's assessment about not really being used by the\ndevices in the wild (obviously nothing changed here).\n\nIf we consider the semantic of unit check with command reject, it's\na surprisingly good match: basically device detected a programming\nerror (which can not be detected by the channel-subsystem because it\nis device (type) specific). For reference see:\nhttp://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/dz9ar110/2.7.2.1?DT=19920904110920\n\nIMHO that's almost exactly what we have here: the channel-program\nis good from the perspective of the channel subsystem, but the device\ncan't deal with it. So we would not lie that the device is at fault\n(was Connie's concern initially) but we would not lie about having\na generally invalid channel program (was my concern).\n\nSo how about an unit check with a command reject? (The only problem\nI see is is on the device vs device type plane -- but that ain't better\nfor unit exception.)\n\nHalil","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xnyFv5C6lz9s7C\n\tfor ;\n\tThu, 7 Sep 2017 21:02:09 +1000 (AEST)","from localhost ([::1]:39811 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpuZT-0004Ee-Bj\n\tfor incoming@patchwork.ozlabs.org; Thu, 07 Sep 2017 07:02:07 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:36486)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpuZA-0004ES-1G\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 07:01:49 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpuZ6-0003z9-3K\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 07:01:48 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:54529)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dpuZ5-0003x5-QC\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 07:01:44 -0400","from pps.filterd (m0098396.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv87B0cU6089529\n\tfor ; Thu, 7 Sep 2017 07:01:41 -0400","from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2cu21tgt3g-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Thu, 07 Sep 2017 07:01:40 -0400","from localhost\n\tby e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tThu, 7 Sep 2017 12:01:37 +0100","from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195)\n\tby e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tThu, 7 Sep 2017 12:01:35 +0100","from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com\n\t[9.149.105.232])\n\tby b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v87B1ZsE28770366; Thu, 7 Sep 2017 11:01:35 GMT","from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 254E452045;\n\tThu, 7 Sep 2017 10:56:51 +0100 (BST)","from oc3836556865.ibm.com (unknown [9.152.224.207])\n\tby d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id CF24B5203F; \n\tThu, 7 Sep 2017 10:56:50 +0100 (BST)"],"To":"Cornelia Huck ,\n\tDong Jia Shi ,\n\tPierre Morel , qemu-devel@nongnu.org","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-3-pasic@linux.vnet.ibm.com>\n\t<20170831111953.242ddc28.cohuck@redhat.com>\n\t\n\t<20170905100234.7a92128e.cohuck@redhat.com>\n\t\n\t<20170905174606.1e0c6404.cohuck@redhat.com>\n\t<24e87c3e-2674-8fc1-cd0a-94f4907ddc7d@linux.vnet.ibm.com>\n\t<20170906082720.GZ31680@bjsdjshi@linux.vnet.ibm.com>\n\t<20170906132538.73b31142.cohuck@redhat.com>\n\t<20170907080208.GE31680@bjsdjshi@linux.vnet.ibm.com>","From":"Halil Pasic ","Date":"Thu, 7 Sep 2017 13:01:34 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.0","MIME-Version":"1.0","In-Reply-To":"<20170907080208.GE31680@bjsdjshi@linux.vnet.ibm.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","X-TM-AS-GCONF":"00","x-cbid":"17090711-0020-0000-0000-000003B63823","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17090711-0021-0000-0000-000042473AFF","Message-Id":"","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-07_07:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709070162","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 2/9] s390x: fix invalid use of cc 1 for SSCH","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1767753,"web_url":"http://patchwork.ozlabs.org/comment/1767753/","msgid":"<20170913120856.28341e7b.cohuck@redhat.com>","list_archive_url":null,"date":"2017-09-13T10:08:56","subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","submitter":{"id":71914,"url":"http://patchwork.ozlabs.org/api/people/71914/","name":"Cornelia Huck","email":"cohuck@redhat.com"},"content":"On Thu, 7 Sep 2017 13:01:34 +0200\nHalil Pasic wrote:\n\n> On 09/07/2017 10:02 AM, Dong Jia Shi wrote:\n> > * Cornelia Huck [2017-09-06 13:25:38 +0200]:\n> > \n> >> On Wed, 6 Sep 2017 16:27:20 +0800\n> >> Dong Jia Shi wrote:\n> >> \n> >>> * Halil Pasic [2017-09-05 19:20:43 +0200]:\n> >>> \n> >>>>\n> >>>>\n> >>>> On 09/05/2017 05:46 PM, Cornelia Huck wrote: \n> >>>>> On Tue, 5 Sep 2017 17:24:19 +0200\n> >>>>> Halil Pasic wrote:\n> >>>>> \n> >>>>>> My problem with a program check (indicated by SCSW word 2 bit 10) is\n> >>>>>> that, in my reading of the architecture, the semantic behind it is: The\n> >>>>>> channel subsystem (not the cu or device) has detected, that the \n> >>>>>> the channel program (previously submitted as an ORB) is erroneous. Which\n> >>>>>> programs are erroneous is specified by the architecture. What we have\n> >>>>>> here does not qualify.\n> >>>>>>\n> >>>>>> My idea was to rather blame the virtual hardware (device) and put no blame\n> >>>>>> on the program nor he channel subsystem. This could be done using device\n> >>>>>> status (unit check with command reject, maybe unit exception) or interface\n> >>>>>> check. My train of thought was, the problem is not consistent across a\n> >>>>>> device type, so it has to be device specific. \n> >>>>>\n> >>>>> Unit exception might be a better way to express what is happening here.\n> >>>>> At least, it moves us away from cc 1 and not towards cc 3 :)\n> >>>>> \n> >>>>\n> >>>> I will do a follow up patch pursuing device exception.\n> >>>> \n> >>>>>>\n> >>>>>> Of course blaming the device could mislead the person encountering the\n> >>>>>> problem, and make him believe it's an non-virtual hardware problem.\n> >>>>>>\n> >>>>>> About the misleading, I think the best we can do is log out a message\n> >>>>>> indicating what really happened. \n> >>>>>\n> >>>>> Just document it in the code? If it doesn't happen with Linux as a\n> >>>>> guest, it is highly unlikely to be seen in the wild.\n> >>>>> \n> >>>>\n> >>>>\n> >>>> Well we have two problems here:\n> >>>> 1) Unit exception can be already defined by the device type for the\n> >>>> command (reference: http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/dz9ar110/2.6.10?DT=19920904110920).\n> >>>> I think this one is what you mean. And I agree that's best handled\n> >>>> with comment in code. \n> >>> Using unit check, with bit 3 byte 0 of the sense data set to 1, to\n> >>> indicate an 'Equipment check', sounds a bit more proper than unit\n> >>> exception. \n> >>\n> >> I don't agree: Equipment check sounds a lot more dire (and seems to\n> >> imply a malfunction). I like unit exception better. \n> > Got the point. Fair enough!\n> > \n> \n> I do see some benefit in doing unit check over unit exception. Just\n> kept quite to see the discussion unfold. As already said, unit exception\n> seems to be something reserved for the device type to define in a more\n> or less arbitrary but unambiguous way. I agreed to use this, because\n> I trust Connie's assessment about not really being used by the\n> devices in the wild (obviously nothing changed here).\n> \n> If we consider the semantic of unit check with command reject, it's\n> a surprisingly good match: basically device detected a programming\n> error (which can not be detected by the channel-subsystem because it\n> is device (type) specific). For reference see:\n> http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/dz9ar110/2.7.2.1?DT=19920904110920\n> \n> IMHO that's almost exactly what we have here: the channel-program\n> is good from the perspective of the channel subsystem, but the device\n> can't deal with it. So we would not lie that the device is at fault\n> (was Connie's concern initially) but we would not lie about having\n> a generally invalid channel program (was my concern).\n> \n> So how about an unit check with a command reject? (The only problem\n> I see is is on the device vs device type plane -- but that ain't better\n> for unit exception.)\n\nI don't know, it feels a bit weird if I look at the cases where I saw\ncommand reject in the wild before, even if seems to agree with the\narchitecture... but just a gut feeling.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","ext-mx10.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx10.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=cohuck@redhat.com"],"Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xscpK5hgjz9s9Y\n\tfor ;\n\tWed, 13 Sep 2017 20:09:27 +1000 (AEST)","from localhost ([::1]:41320 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1ds4bl-0005cR-DY\n\tfor incoming@patchwork.ozlabs.org; Wed, 13 Sep 2017 06:09:25 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:40150)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1ds4bQ-0005bm-QQ\n\tfor qemu-devel@nongnu.org; Wed, 13 Sep 2017 06:09:06 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1ds4bM-0002SK-SF\n\tfor qemu-devel@nongnu.org; Wed, 13 Sep 2017 06:09:04 -0400","from mx1.redhat.com ([209.132.183.28]:48348)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1ds4bM-0002RV-J7\n\tfor qemu-devel@nongnu.org; Wed, 13 Sep 2017 06:09:00 -0400","from smtp.corp.redhat.com\n\t(int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 7E7595D689;\n\tWed, 13 Sep 2017 10:08:59 +0000 (UTC)","from gondolin (dhcp-192-215.str.redhat.com [10.33.192.215])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 834E960841;\n\tWed, 13 Sep 2017 10:08:58 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 7E7595D689","Date":"Wed, 13 Sep 2017 12:08:56 +0200","From":"Cornelia Huck ","To":"Halil Pasic ","Message-ID":"<20170913120856.28341e7b.cohuck@redhat.com>","In-Reply-To":"","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-3-pasic@linux.vnet.ibm.com>\n\t<20170831111953.242ddc28.cohuck@redhat.com>\n\t\n\t<20170905100234.7a92128e.cohuck@redhat.com>\n\t\n\t<20170905174606.1e0c6404.cohuck@redhat.com>\n\t<24e87c3e-2674-8fc1-cd0a-94f4907ddc7d@linux.vnet.ibm.com>\n\t<20170906082720.GZ31680@bjsdjshi@linux.vnet.ibm.com>\n\t<20170906132538.73b31142.cohuck@redhat.com>\n\t<20170907080208.GE31680@bjsdjshi@linux.vnet.ibm.com>\n\t","Organization":"Red Hat GmbH","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.13","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.39]);\n\tWed, 13 Sep 2017 10:08:59 +0000 (UTC)","X-detected-operating-system":"by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]\n\t[fuzzy]","X-Received-From":"209.132.183.28","Subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Dong Jia Shi ,\n\tPierre Morel , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1767910,"web_url":"http://patchwork.ozlabs.org/comment/1767910/","msgid":"<5405aa24-3d79-b5fb-da42-c550d0d09a47@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-13T14:05:34","subject":"Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH","submitter":{"id":68297,"url":"http://patchwork.ozlabs.org/api/people/68297/","name":"Halil Pasic","email":"pasic@linux.vnet.ibm.com"},"content":"On 09/13/2017 12:08 PM, Cornelia Huck wrote:\n> On Thu, 7 Sep 2017 13:01:34 +0200\n> Halil Pasic wrote:\n> \n>> On 09/07/2017 10:02 AM, Dong Jia Shi wrote:\n>>> * Cornelia Huck [2017-09-06 13:25:38 +0200]:\n>>> \n>>>> On Wed, 6 Sep 2017 16:27:20 +0800\n>>>> Dong Jia Shi wrote:\n>>>> \n>>>>> * Halil Pasic [2017-09-05 19:20:43 +0200]:\n>>>>> \n>>>>>>\n>>>>>>\n>>>>>> On 09/05/2017 05:46 PM, Cornelia Huck wrote: \n>>>>>>> On Tue, 5 Sep 2017 17:24:19 +0200\n>>>>>>> Halil Pasic wrote:\n>>>>>>> \n>>>>>>>> My problem with a program check (indicated by SCSW word 2 bit 10) is\n>>>>>>>> that, in my reading of the architecture, the semantic behind it is: The\n>>>>>>>> channel subsystem (not the cu or device) has detected, that the \n>>>>>>>> the channel program (previously submitted as an ORB) is erroneous. Which\n>>>>>>>> programs are erroneous is specified by the architecture. What we have\n>>>>>>>> here does not qualify.\n>>>>>>>>\n>>>>>>>> My idea was to rather blame the virtual hardware (device) and put no blame\n>>>>>>>> on the program nor he channel subsystem. This could be done using device\n>>>>>>>> status (unit check with command reject, maybe unit exception) or interface\n>>>>>>>> check. My train of thought was, the problem is not consistent across a\n>>>>>>>> device type, so it has to be device specific. \n>>>>>>>\n>>>>>>> Unit exception might be a better way to express what is happening here.\n>>>>>>> At least, it moves us away from cc 1 and not towards cc 3 :)\n>>>>>>> \n>>>>>>\n>>>>>> I will do a follow up patch pursuing device exception.\n>>>>>> \n>>>>>>>>\n>>>>>>>> Of course blaming the device could mislead the person encountering the\n>>>>>>>> problem, and make him believe it's an non-virtual hardware problem.\n>>>>>>>>\n>>>>>>>> About the misleading, I think the best we can do is log out a message\n>>>>>>>> indicating what really happened. \n>>>>>>>\n>>>>>>> Just document it in the code? If it doesn't happen with Linux as a\n>>>>>>> guest, it is highly unlikely to be seen in the wild.\n>>>>>>> \n>>>>>>\n>>>>>>\n>>>>>> Well we have two problems here:\n>>>>>> 1) Unit exception can be already defined by the device type for the\n>>>>>> command (reference: http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/dz9ar110/2.6.10?DT=19920904110920).\n>>>>>> I think this one is what you mean. And I agree that's best handled\n>>>>>> with comment in code. \n>>>>> Using unit check, with bit 3 byte 0 of the sense data set to 1, to\n>>>>> indicate an 'Equipment check', sounds a bit more proper than unit\n>>>>> exception. \n>>>>\n>>>> I don't agree: Equipment check sounds a lot more dire (and seems to\n>>>> imply a malfunction). I like unit exception better. \n>>> Got the point. Fair enough!\n>>> \n>>\n>> I do see some benefit in doing unit check over unit exception. Just\n>> kept quite to see the discussion unfold. As already said, unit exception\n>> seems to be something reserved for the device type to define in a more\n>> or less arbitrary but unambiguous way. I agreed to use this, because\n>> I trust Connie's assessment about not really being used by the\n>> devices in the wild (obviously nothing changed here).\n>>\n>> If we consider the semantic of unit check with command reject, it's\n>> a surprisingly good match: basically device detected a programming\n>> error (which can not be detected by the channel-subsystem because it\n>> is device (type) specific). For reference see:\n>> http://publibfp.dhe.ibm.com/cgi-bin/bookmgr/BOOKS/dz9ar110/2.7.2.1?DT=19920904110920\n>>\n>> IMHO that's almost exactly what we have here: the channel-program\n>> is good from the perspective of the channel subsystem, but the device\n>> can't deal with it. So we would not lie that the device is at fault\n>> (was Connie's concern initially) but we would not lie about having\n>> a generally invalid channel program (was my concern).\n>>\n>> So how about an unit check with a command reject? (The only problem\n>> I see is is on the device vs device type plane -- but that ain't better\n>> for unit exception.)\n> \n> I don't know, it feels a bit weird if I look at the cases where I saw\n> command reject in the wild before, even if seems to agree with the\n> architecture... but just a gut feeling.\n> \n\nThen let's settle for unit exception for now. I will let this topic\n(series) rest for a couple of days in favor of things like virtio-crypto\nspec review, maybe IDA, and some other stuff. But I definitely intend\nto pick this series up again.\n\nHalil","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=nongnu.org\n\t(client-ip=2001:4830:134:3::11; helo=lists.gnu.org;\n\tenvelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n\treceiver=)","Received":["from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11])\n\t(using TLSv1 with cipher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xsk3f5cHWz9sPs\n\tfor ;\n\tThu, 14 Sep 2017 00:06:21 +1000 (AEST)","from localhost ([::1]:42708 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1ds8J1-00023A-2L\n\tfor incoming@patchwork.ozlabs.org; Wed, 13 Sep 2017 10:06:19 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:56557)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1ds8IU-00021B-QL\n\tfor qemu-devel@nongnu.org; Wed, 13 Sep 2017 10:05:48 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1ds8IQ-0002c6-5N\n\tfor qemu-devel@nongnu.org; Wed, 13 Sep 2017 10:05:46 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:57248)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1ds8IP-0002bQ-MJ\n\tfor qemu-devel@nongnu.org; Wed, 13 Sep 2017 10:05:42 -0400","from pps.filterd (m0098394.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8DE4PAU049832\n\tfor ; Wed, 13 Sep 2017 10:05:40 -0400","from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com [195.75.94.107])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2cy579kah5-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Wed, 13 Sep 2017 10:05:39 -0400","from localhost\n\tby e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tWed, 13 Sep 2017 15:05:37 +0100","from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196)\n\tby e06smtp11.uk.ibm.com (192.168.101.141) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tWed, 13 Sep 2017 15:05:35 +0100","from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com\n\t[9.149.105.61])\n\tby b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v8DE5YV619726428; Wed, 13 Sep 2017 14:05:34 GMT","from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 75F1E11C04A;\n\tWed, 13 Sep 2017 15:01:46 +0100 (BST)","from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 1D7A411C04C;\n\tWed, 13 Sep 2017 15:01:46 +0100 (BST)","from oc3836556865.ibm.com (unknown [9.152.224.207])\n\tby d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP;\n\tWed, 13 Sep 2017 15:01:46 +0100 (BST)"],"To":"Cornelia Huck ","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-3-pasic@linux.vnet.ibm.com>\n\t<20170831111953.242ddc28.cohuck@redhat.com>\n\t\n\t<20170905100234.7a92128e.cohuck@redhat.com>\n\t\n\t<20170905174606.1e0c6404.cohuck@redhat.com>\n\t<24e87c3e-2674-8fc1-cd0a-94f4907ddc7d@linux.vnet.ibm.com>\n\t<20170906082720.GZ31680@bjsdjshi@linux.vnet.ibm.com>\n\t<20170906132538.73b31142.cohuck@redhat.com>\n\t<20170907080208.GE31680@bjsdjshi@linux.vnet.ibm.com>\n\t\n\t<20170913120856.28341e7b.cohuck@redhat.com>","From":"Halil Pasic ","Date":"Wed, 13 Sep 2017 16:05:34 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.0","MIME-Version":"1.0","In-Reply-To":"<20170913120856.28341e7b.cohuck@redhat.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-TM-AS-GCONF":"00","x-cbid":"17091314-0040-0000-0000-000003F9ABF3","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17091314-0041-0000-0000-0000209AC74C","Message-Id":"<5405aa24-3d79-b5fb-da42-c550d0d09a47@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-13_04:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709130220","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 2/9] s390x: fix invalid use of cc 1 for SSCH","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Dong Jia Shi ,\n\tPierre Morel , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}}]