[{"id":1760797,"web_url":"http://patchwork.ozlabs.org/comment/1760797/","msgid":"<20170831115535.1e4201d3.cohuck@redhat.com>","list_archive_url":null,"date":"2017-08-31T09:55:35","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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:04 +0200\nHalil Pasic wrote:\n\n> Simplify the error handling of the SSCH and RSCH handler avoiding\n> arbitrary and cryptic error codes being mapped to what a subchannel is\n> supposed to do. Let the code detecting the condition tell how it's to be\n> handled in a less ambiguous way. It's best to handle SSCH and RSCH in\n> one go as the emulation of the two shares a lot of code.\n\nSo determining the return code at the point in time where we can\ninstead of trying to map to return codes and back again makes quite a\nbit of sense, but I'll have to look at the rest of this. For one thing,\nwould a better split to introduce the cc-reporting infrastructure first\nand then convert the different I/O functions?\n\n> \n> Signed-off-by: Halil Pasic \n> Acked-by: Pierre Morel\n> \n> ---\n> Notes:\n> Funny, we had a different swich-case for SSCH and RSCH. For\n> virtual it did not matter, but for passtrough it could. In practice\n> -EINVAL from the kernel would have been mapped to cc 2 in case of\n> RSCH and to cc 1 in case of SSHC which is absurd. Same goes for\n> -EBUSY from kernel which is correctly mapped to cc 2 in case of\n> SSCH, but for RSCH it gets mapped to cc 1 which is also absurd.\n> ---\n> hw/s390x/css.c | 86 ++++++++++++++-------------------------------\n> hw/s390x/s390-ccw.c | 8 ++---\n> hw/vfio/ccw.c | 32 +++++++++++++----\n> include/hw/s390x/css.h | 30 ++++++++++++----\n> include/hw/s390x/s390-ccw.h | 2 +-\n> target/s390x/ioinst.c | 61 +++++++++-----------------------\n> 6 files changed, 97 insertions(+), 122 deletions(-)\n> \n> diff --git a/hw/s390x/css.c b/hw/s390x/css.c\n> index bc47bf5b20..1102642c10 100644\n> --- a/hw/s390x/css.c\n> +++ b/hw/s390x/css.c\n> @@ -1015,12 +1015,11 @@ static void sch_handle_start_func_virtual(SubchDev *sch)\n> \n> }\n> \n> -static int sch_handle_start_func_passthrough(SubchDev *sch)\n> +static void sch_handle_start_func_passthrough(SubchDev *sch)\n> {\n> \n> PMCW *p = &sch->curr_status.pmcw;\n> SCSW *s = &sch->curr_status.scsw;\n> - int ret;\n> \n> ORB *orb = &sch->orb;\n> if (!(s->ctrl & SCSW_ACTL_SUSP)) {\n> @@ -1034,28 +1033,10 @@ 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 -ENODEV;\n> + sch->iret.cc = 3;\n\nSame as already commented: I don't think cc 3 is a good match.\n\n> }\n> \n> - ret = s390_ccw_cmd_request(orb, s, sch->driver_data);\n> - switch (ret) {\n> - /* Currently we don't update control block and just return the cc code. */\n> - case 0:\n> - break;\n> - case -EBUSY:\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> - default:\n> - /* Let's make all other return codes map to cc 3. */\n> - ret = -ENODEV;\n> - };\n> -\n> - return ret;\n> + s390_ccw_cmd_request(sch);\n\nAs you change the handling anyway: Don't change this logic in prior\npatches?\n\n> }\n> \n> /*\n> @@ -1064,7 +1045,7 @@ static int sch_handle_start_func_passthrough(SubchDev *sch)\n> * read/writes) asynchronous later on if we start supporting more than\n> * our current very simple devices.\n> */\n> -int do_subchannel_work_virtual(SubchDev *sch)\n> +void do_subchannel_work_virtual(SubchDev *sch)\n> {\n> \n> SCSW *s = &sch->curr_status.scsw;\n> @@ -1078,41 +1059,35 @@ int do_subchannel_work_virtual(SubchDev *sch)\n> sch_handle_start_func_virtual(sch);\n> } else {\n> /* Cannot happen. */\n> - return -ENODEV;\n> + sch->iret.cc = 3;\n\nSee comment for the last patch.\n\n> }\n> css_inject_io_interrupt(sch);\n> - return 0;\n> }\n> \n> -int do_subchannel_work_passthrough(SubchDev *sch)\n> +void do_subchannel_work_passthrough(SubchDev *sch)\n> {\n> - int ret;\n> SCSW *s = &sch->curr_status.scsw;\n> \n> if (s->ctrl & SCSW_FCTL_CLEAR_FUNC) {\n> /* TODO: Clear handling */\n> sch_handle_clear_func(sch);\n> - ret = 0;\n> } else if (s->ctrl & SCSW_FCTL_HALT_FUNC) {\n> /* TODO: Halt handling */\n> sch_handle_halt_func(sch);\n> - ret = 0;\n> } else if (s->ctrl & SCSW_FCTL_START_FUNC) {\n> - ret = sch_handle_start_func_passthrough(sch);\n> + sch_handle_start_func_passthrough(sch);\n> } else {\n> /* Cannot happen. */\n> - return -ENODEV;\n> + sch->iret.cc = 3;\n\nftcl == 0 should have been rejected already by the function handlers\nhere as well, shouldn't it?\n\n> }\n> -\n> - return ret;\n> }\n> \n> -static int do_subchannel_work(SubchDev *sch)\n> +static void do_subchannel_work(SubchDev *sch)\n> {\n> if (sch->do_subchannel_work) {\n> - return sch->do_subchannel_work(sch);\n> + sch->do_subchannel_work(sch);\n> } else {\n> - return -ENODEV;\n> + sch->iret.cc = 3;\n\nSee my comment for a prior patch.\n\n> }\n> }\n> \n\n(...)\n\n> diff --git a/include/hw/s390x/css.h b/include/hw/s390x/css.h\n> index 5c5fe6b202..d093181a9e 100644\n> --- a/include/hw/s390x/css.h\n> +++ b/include/hw/s390x/css.h\n> @@ -94,13 +94,31 @@ struct SubchDev {\n> /* transport-provided data: */\n> int (*ccw_cb) (SubchDev *, CCW1);\n> void (*disable_cb)(SubchDev *);\n> - int (*do_subchannel_work) (SubchDev *);\n> + void (*do_subchannel_work) (SubchDev *);\n> SenseId id;\n> void *driver_data;\n> + /* io instructions conclude according to iret */\n> + struct {\n> + /*\n> + * General semantic of cc codes of IO instructions is (brief):\n> + * 0 -- produced expected result\n> + * 1 -- produced alternate result\n> + * 2 -- ineffective, because busy with previously initiated function\n> + * 3 -- ineffective, not operational\n\nI'm not sure you can summarize this that way in all cases.\n\nAlso, what does \"ineffective\" mean? If I get a cc 1 for, say, ssch, I\ndon't expect something either as the subchannel was already status\npending.\n\n> + */\n> + uint32_t cc:4;\n> + bool pgm_chk:1;\n\nThis looks weird?\n\n> + uint32_t irq_code;\n> + } iret;\n> };\n> \n> extern const VMStateDescription vmstate_subch_dev;\n\n(...)\n\n> @@ -238,33 +236,17 @@ void ioinst_handle_ssch(S390CPU *cpu, uint64_t reg1, uint32_t ipb)\n> }\n> trace_ioinst_sch_id(\"ssch\", cssid, ssid, schid);\n> sch = css_find_subch(m, cssid, ssid, schid);\n> - if (sch && css_subch_visible(sch)) {\n> - ret = css_do_ssch(sch, &orb);\n> + if (!sch || !css_subch_visible(sch)) {\n> + setcc(cpu, 3);\n> + return;\n> }\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\nYou removed the TODO :(\n\nThere still might be a better way to reflect this...\n\n> - program_interrupt(env, PGM_ADDRESSING, 4);\n> + css_subch_clear_iret(sch);\n> + css_do_ssch(sch, &orb);\n> + if (sch->iret.pgm_chk) {\n> + program_interrupt(env, sch->iret.irq_code, 4);\n> return;\n> - case 0:\n> - cc = 0;\n> - break;\n> - default:\n> - cc = 1;\n> - break;\n> }\n> - setcc(cpu, cc);\n> + setcc(cpu, sch->iret.cc);\n> }\n> \n> void ioinst_handle_stcrw(S390CPU *cpu, uint32_t ipb)","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 3xjd6x1XhZz9sPt\n\tfor ;\n\tThu, 31 Aug 2017 19:56:09 +1000 (AEST)","from localhost ([::1]:54717 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dnMCj-0007Zk-V3\n\tfor incoming@patchwork.ozlabs.org; Thu, 31 Aug 2017 05:56:06 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:32778)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dnMCP-0007ZV-ER\n\tfor qemu-devel@nongnu.org; Thu, 31 Aug 2017 05:55:46 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dnMCL-0006KS-VG\n\tfor qemu-devel@nongnu.org; Thu, 31 Aug 2017 05:55:45 -0400","from mx1.redhat.com ([209.132.183.28]:34730)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dnMCL-0006Jr-KE\n\tfor qemu-devel@nongnu.org; Thu, 31 Aug 2017 05:55:41 -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 4C222155E2;\n\tThu, 31 Aug 2017 09:55:40 +0000 (UTC)","from gondolin (dhcp-192-215.str.redhat.com [10.33.192.215])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 661809C131;\n\tThu, 31 Aug 2017 09:55:39 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 4C222155E2","Date":"Thu, 31 Aug 2017 11:55:35 +0200","From":"Cornelia Huck ","To":"Halil Pasic ","Message-ID":"<20170831115535.1e4201d3.cohuck@redhat.com>","In-Reply-To":"<20170830163609.50260-5-pasic@linux.vnet.ibm.com>","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-5-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.16","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.29]);\n\tThu, 31 Aug 2017 09:55:40 +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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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":1763465,"web_url":"http://patchwork.ozlabs.org/comment/1763465/","msgid":"<7540741b-d230-e7c4-50d3-036f31997c8b@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-05T15:55:17","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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:55 AM, Cornelia Huck wrote:\n> On Wed, 30 Aug 2017 18:36:04 +0200\n> Halil Pasic wrote:\n> \n>> Simplify the error handling of the SSCH and RSCH handler avoiding\n>> arbitrary and cryptic error codes being mapped to what a subchannel is\n>> supposed to do. Let the code detecting the condition tell how it's to be\n>> handled in a less ambiguous way. It's best to handle SSCH and RSCH in\n>> one go as the emulation of the two shares a lot of code.\n> \n> So determining the return code at the point in time where we can\n> instead of trying to map to return codes and back again makes quite a\n> bit of sense, but I'll have to look at the rest of this.\n\n\nLooging forward to.\n\n> For one thing,\n> would a better split to introduce the cc-reporting infrastructure first\n> and then convert the different I/O functions?\n> \n\nSpeaks nothing against it, although I don't see anything wrong with\nnot introducing unused infrastructure (that is introducing\nthe infrastructure and it's first user together). As you prefer.\n\n>>\n>> Signed-off-by: Halil Pasic \n>> Acked-by: Pierre Morel\n>>\n>> ---\n>> Notes:\n>> Funny, we had a different swich-case for SSCH and RSCH. For\n>> virtual it did not matter, but for passtrough it could. In practice\n>> -EINVAL from the kernel would have been mapped to cc 2 in case of\n>> RSCH and to cc 1 in case of SSHC which is absurd. Same goes for\n>> -EBUSY from kernel which is correctly mapped to cc 2 in case of\n>> SSCH, but for RSCH it gets mapped to cc 1 which is also absurd.\n>> ---\n>> hw/s390x/css.c | 86 ++++++++++++++-------------------------------\n>> hw/s390x/s390-ccw.c | 8 ++---\n>> hw/vfio/ccw.c | 32 +++++++++++++----\n>> include/hw/s390x/css.h | 30 ++++++++++++----\n>> include/hw/s390x/s390-ccw.h | 2 +-\n>> target/s390x/ioinst.c | 61 +++++++++-----------------------\n>> 6 files changed, 97 insertions(+), 122 deletions(-)\n>>\n>> diff --git a/hw/s390x/css.c b/hw/s390x/css.c\n>> index bc47bf5b20..1102642c10 100644\n>> --- a/hw/s390x/css.c\n>> +++ b/hw/s390x/css.c\n>> @@ -1015,12 +1015,11 @@ static void sch_handle_start_func_virtual(SubchDev *sch)\n>> \n>> }\n>> \n>> -static int sch_handle_start_func_passthrough(SubchDev *sch)\n>> +static void sch_handle_start_func_passthrough(SubchDev *sch)\n>> {\n>> \n>> PMCW *p = &sch->curr_status.pmcw;\n>> SCSW *s = &sch->curr_status.scsw;\n>> - int ret;\n>> \n>> ORB *orb = &sch->orb;\n>> if (!(s->ctrl & SCSW_ACTL_SUSP)) {\n>> @@ -1034,28 +1033,10 @@ 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 -ENODEV;\n>> + sch->iret.cc = 3;\n> \n> Same as already commented: I don't think cc 3 is a good match.\n> \n\nYeah, this is just dumb conversion.\n\n>> }\n>> \n>> - ret = s390_ccw_cmd_request(orb, s, sch->driver_data);\n>> - switch (ret) {\n>> - /* Currently we don't update control block and just return the cc code. */\n>> - case 0:\n>> - break;\n>> - case -EBUSY:\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>> - default:\n>> - /* Let's make all other return codes map to cc 3. */\n>> - ret = -ENODEV;\n>> - };\n>> -\n>> - return ret;\n>> + s390_ccw_cmd_request(sch);\n> \n> As you change the handling anyway: Don't change this logic in prior\n> patches?\n\nI preserve the logic as altered by the previous patches (at least,\nthat is the intention). This is the mapping around part which is going\naway if we push the handling down.\n\n> \n>> }\n>> \n>> /*\n>> @@ -1064,7 +1045,7 @@ static int sch_handle_start_func_passthrough(SubchDev *sch)\n>> * read/writes) asynchronous later on if we start supporting more than\n>> * our current very simple devices.\n>> */\n>> -int do_subchannel_work_virtual(SubchDev *sch)\n>> +void do_subchannel_work_virtual(SubchDev *sch)\n>> {\n>> \n>> SCSW *s = &sch->curr_status.scsw;\n>> @@ -1078,41 +1059,35 @@ int do_subchannel_work_virtual(SubchDev *sch)\n>> sch_handle_start_func_virtual(sch);\n>> } else {\n>> /* Cannot happen. */\n>> - return -ENODEV;\n>> + sch->iret.cc = 3;\n> \n> See comment for the last patch.\n> \n\nAgain just a conversion. If we don't do it in the previous patch\nit has to be done differently in this patch.\n\n>> }\n>> css_inject_io_interrupt(sch);\n>> - return 0;\n>> }\n>> \n>> -int do_subchannel_work_passthrough(SubchDev *sch)\n>> +void do_subchannel_work_passthrough(SubchDev *sch)\n>> {\n>> - int ret;\n>> SCSW *s = &sch->curr_status.scsw;\n>> \n>> if (s->ctrl & SCSW_FCTL_CLEAR_FUNC) {\n>> /* TODO: Clear handling */\n>> sch_handle_clear_func(sch);\n>> - ret = 0;\n>> } else if (s->ctrl & SCSW_FCTL_HALT_FUNC) {\n>> /* TODO: Halt handling */\n>> sch_handle_halt_func(sch);\n>> - ret = 0;\n>> } else if (s->ctrl & SCSW_FCTL_START_FUNC) {\n>> - ret = sch_handle_start_func_passthrough(sch);\n>> + sch_handle_start_func_passthrough(sch);\n>> } else {\n>> /* Cannot happen. */\n>> - return -ENODEV;\n>> + sch->iret.cc = 3;\n> \n> ftcl == 0 should have been rejected already by the function handlers\n> here as well, shouldn't it?\n\nWhich function handlers. Basically the instruction handlers set fctl\nand call do_subchannel_work to get the indicated work done.\n\n> \n>> }\n>> -\n>> - return ret;\n>> }\n>> \n>> -static int do_subchannel_work(SubchDev *sch)\n>> +static void do_subchannel_work(SubchDev *sch)\n>> {\n>> if (sch->do_subchannel_work) {\n>> - return sch->do_subchannel_work(sch);\n>> + sch->do_subchannel_work(sch);\n>> } else {\n>> - return -ENODEV;\n>> + sch->iret.cc = 3;\n> \n> See my comment for a prior patch.\n>\n\nNod.\n\n \n>> }\n>> }\n>> \n> \n> (...)\n> \n>> diff --git a/include/hw/s390x/css.h b/include/hw/s390x/css.h\n>> index 5c5fe6b202..d093181a9e 100644\n>> --- a/include/hw/s390x/css.h\n>> +++ b/include/hw/s390x/css.h\n>> @@ -94,13 +94,31 @@ struct SubchDev {\n>> /* transport-provided data: */\n>> int (*ccw_cb) (SubchDev *, CCW1);\n>> void (*disable_cb)(SubchDev *);\n>> - int (*do_subchannel_work) (SubchDev *);\n>> + void (*do_subchannel_work) (SubchDev *);\n>> SenseId id;\n>> void *driver_data;\n>> + /* io instructions conclude according to iret */\n>> + struct {\n>> + /*\n>> + * General semantic of cc codes of IO instructions is (brief):\n>> + * 0 -- produced expected result\n>> + * 1 -- produced alternate result\n>> + * 2 -- ineffective, because busy with previously initiated function\n>> + * 3 -- ineffective, not operational\n> \n> I'm not sure you can summarize this that way in all cases.\n> \n> Also, what does \"ineffective\" mean? If I get a cc 1 for, say, ssch, I\n> don't expect something either as the subchannel was already status\n> pending.\n\nYou are right cc 1 would have been better off with\n 'produced alternate result or status pending'\n\nI've tried to make this shorter (from PoP 14-2):\n\"\"\"\nCondition Code 0: Instruction execution produced\nthe expected or most probable result. (See “Deferred\nCondition Code (CC)” on page 9 for a description of\nconditions that can be encountered subsequent to\nthe presentation of condition code 0 that result in a\nnonzero deferred condition code.)\nCondition Code 1: Instruction execution produced\nthe alternate or second-most-probable result, or sta-\ntus conditions were present that may or may not have\nprevented the expected result.\nCondition Code 2: Instruction execution was inef-\nfective because the designated subchannel or chan-\nnel-subsystem facility was busy with a previously\ninitiated function.\nCondition Code 3: Instruction execution was inef-\nfective because the designated element was not\noperational or because some condition precluded ini-\ntiation of the normal function.\n\"\"\"\n\nWell ineffective means not-effective ;).\n\n> \n>> + */\n>> + uint32_t cc:4;\n>> + bool pgm_chk:1;\n> \n> This looks weird?>\n\nWhat do you mean? Any suggestions how to do it better?\n \n>> + uint32_t irq_code;\n>> + } iret;\n>> };\n>> \n>> extern const VMStateDescription vmstate_subch_dev;\n> \n> (...)\n> \n>> @@ -238,33 +236,17 @@ void ioinst_handle_ssch(S390CPU *cpu, uint64_t reg1, uint32_t ipb)\n>> }\n>> trace_ioinst_sch_id(\"ssch\", cssid, ssid, schid);\n>> sch = css_find_subch(m, cssid, ssid, schid);\n>> - if (sch && css_subch_visible(sch)) {\n>> - ret = css_do_ssch(sch, &orb);\n>> + if (!sch || !css_subch_visible(sch)) {\n>> + setcc(cpu, 3);\n>> + return;\n>> }\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> \n> You removed the TODO :(\n> \n> There still might be a better way to reflect this...\n> \n\nOK I should have pushed it down to \n@@ -71,10 +72,27 @@ again:\n goto again;\n }\n error_report(\"vfio-ccw: wirte I/O region failed with errno=%d\", errno);\n- return -errno;\n+ ret = -errno;\n+ } else {\n+ ret = region->ret_code;\n+ }\n+ switch (-ret) {\n+ /* Currently we don't update control block and just return the cc code. */\n+ case 0:\n+ sch->iret.cc = 0;\n+ break;\n+ case EBUSY:\n+ sch->iret.cc = 2;\n+ break;\n+ case EFAULT:\n\nLike this:\n\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+ sch->iret.pgm_chk = true;\n+ sch->iret.irq_code = PGM_ADDRESSING;\n+ break;\n+ case ENODEV:\n+ case EACCES:\n+ default:\n+ sch->iret.cc = 3;\n }\n-\n- return region->ret_code;\n }\n\n static void vfio_ccw_reset(DeviceState *dev)\n\n(deleted in your mail, file hw/vfio/ccw.c).\n\nBut I guess, I was afraid of somebody blaming me for this\ncomment (such TODOs in production code are a bit strange -- what\ndoes it mean: we did not bother to figure it out?).\n\n>> - program_interrupt(env, PGM_ADDRESSING, 4);\n>> + css_subch_clear_iret(sch);\n>> + css_do_ssch(sch, &orb);\n>> + if (sch->iret.pgm_chk) {\n>> + program_interrupt(env, sch->iret.irq_code, 4);\n>> return;\n>> - case 0:\n>> - cc = 0;\n>> - break;\n>> - default:\n>> - cc = 1;\n>> - break;\n>> }\n>> - setcc(cpu, cc);\n>> + setcc(cpu, sch->iret.cc);\n>> }\n>> \n>> void ioinst_handle_stcrw(S390CPU *cpu, uint32_t ipb)\n> \n\nLooking forward to the rest of the feedback.\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 3xmrvN5hzhz9sRm\n\tfor ;\n\tWed, 6 Sep 2017 01:57:20 +1000 (AEST)","from localhost ([::1]:59797 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpGE2-0002sF-SK\n\tfor incoming@patchwork.ozlabs.org; Tue, 05 Sep 2017 11:57:18 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:60166)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpGCH-0001rQ-44\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 11:55:39 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpGCB-0005Kx-IC\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 11:55:29 -0400","from mx0b-001b2d01.pphosted.com ([148.163.158.5]:51158\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 1dpGCB-0005KZ-CR\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 11:55:23 -0400","from pps.filterd (m0098419.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv85Fs4GK107441\n\tfor ; Tue, 5 Sep 2017 11:55:22 -0400","from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com [195.75.94.107])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2csv20hr7t-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Tue, 05 Sep 2017 11:55:22 -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:55:20 +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\tTue, 5 Sep 2017 16:55:19 +0100","from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com\n\t[9.149.105.58])\n\tby b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v85FtIh821364858; Tue, 5 Sep 2017 15:55:18 GMT","from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 2F0094C044;\n\tTue, 5 Sep 2017 16:52:02 +0100 (BST)","from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id BC7F84C046;\n\tTue, 5 Sep 2017 16:52:01 +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:52:01 +0100 (BST)"],"To":"Cornelia Huck ","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-5-pasic@linux.vnet.ibm.com>\n\t<20170831115535.1e4201d3.cohuck@redhat.com>","From":"Halil Pasic ","Date":"Tue, 5 Sep 2017 17:55:17 +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":"<20170831115535.1e4201d3.cohuck@redhat.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","X-TM-AS-GCONF":"00","x-cbid":"17090515-0040-0000-0000-000003F5C45F","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17090515-0041-0000-0000-000020963BF5","Message-Id":"<7540741b-d230-e7c4-50d3-036f31997c8b@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-1709050228","Content-Transfer-Encoding":"quoted-printable","X-MIME-Autoconverted":"from 8bit to quoted-printable by\n\tmx0b-001b2d01.pphosted.com id v85Fs4GK107441","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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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":1763484,"web_url":"http://patchwork.ozlabs.org/comment/1763484/","msgid":"<20170905182546.00457332.cohuck@redhat.com>","list_archive_url":null,"date":"2017-09-05T16:25:46","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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:55:17 +0200\nHalil Pasic wrote:\n\n> On 08/31/2017 11:55 AM, Cornelia Huck wrote:\n> > On Wed, 30 Aug 2017 18:36:04 +0200\n> > Halil Pasic wrote:\n> > \n> >> Simplify the error handling of the SSCH and RSCH handler avoiding\n> >> arbitrary and cryptic error codes being mapped to what a subchannel is\n> >> supposed to do. Let the code detecting the condition tell how it's to be\n> >> handled in a less ambiguous way. It's best to handle SSCH and RSCH in\n> >> one go as the emulation of the two shares a lot of code. \n> > \n> > So determining the return code at the point in time where we can\n> > instead of trying to map to return codes and back again makes quite a\n> > bit of sense, but I'll have to look at the rest of this. \n> \n> \n> Looging forward to.\n\nOnce I manage to find some quiet time for thinking :(\n\n\n> >> - ret = s390_ccw_cmd_request(orb, s, sch->driver_data);\n> >> - switch (ret) {\n> >> - /* Currently we don't update control block and just return the cc code. */\n> >> - case 0:\n> >> - break;\n> >> - case -EBUSY:\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> >> - default:\n> >> - /* Let's make all other return codes map to cc 3. */\n> >> - ret = -ENODEV;\n> >> - };\n> >> -\n> >> - return ret;\n> >> + s390_ccw_cmd_request(sch); \n> > \n> > As you change the handling anyway: Don't change this logic in prior\n> > patches? \n> \n> I preserve the logic as altered by the previous patches (at least,\n> that is the intention). This is the mapping around part which is going\n> away if we push the handling down.\n\nMy point is that you touch the code path twice. But we disagreed on the\noriginal change anyway :)\n\n> >> -int do_subchannel_work_passthrough(SubchDev *sch)\n> >> +void do_subchannel_work_passthrough(SubchDev *sch)\n> >> {\n> >> - int ret;\n> >> SCSW *s = &sch->curr_status.scsw;\n> >> \n> >> if (s->ctrl & SCSW_FCTL_CLEAR_FUNC) {\n> >> /* TODO: Clear handling */\n> >> sch_handle_clear_func(sch);\n> >> - ret = 0;\n> >> } else if (s->ctrl & SCSW_FCTL_HALT_FUNC) {\n> >> /* TODO: Halt handling */\n> >> sch_handle_halt_func(sch);\n> >> - ret = 0;\n> >> } else if (s->ctrl & SCSW_FCTL_START_FUNC) {\n> >> - ret = sch_handle_start_func_passthrough(sch);\n> >> + sch_handle_start_func_passthrough(sch);\n> >> } else {\n> >> /* Cannot happen. */\n> >> - return -ENODEV;\n> >> + sch->iret.cc = 3; \n> > \n> > ftcl == 0 should have been rejected already by the function handlers\n> > here as well, shouldn't it? \n> \n> Which function handlers. Basically the instruction handlers set fctl\n> and call do_subchannel_work to get the indicated work done.\n\nOr set. My point is that we can't get here with fctl == 0. So an assert\nsounds better to me.\n\n\n> >> diff --git a/include/hw/s390x/css.h b/include/hw/s390x/css.h\n> >> index 5c5fe6b202..d093181a9e 100644\n> >> --- a/include/hw/s390x/css.h\n> >> +++ b/include/hw/s390x/css.h\n> >> @@ -94,13 +94,31 @@ struct SubchDev {\n> >> /* transport-provided data: */\n> >> int (*ccw_cb) (SubchDev *, CCW1);\n> >> void (*disable_cb)(SubchDev *);\n> >> - int (*do_subchannel_work) (SubchDev *);\n> >> + void (*do_subchannel_work) (SubchDev *);\n> >> SenseId id;\n> >> void *driver_data;\n> >> + /* io instructions conclude according to iret */\n> >> + struct {\n> >> + /*\n> >> + * General semantic of cc codes of IO instructions is (brief):\n> >> + * 0 -- produced expected result\n> >> + * 1 -- produced alternate result\n> >> + * 2 -- ineffective, because busy with previously initiated function\n> >> + * 3 -- ineffective, not operational \n> > \n> > I'm not sure you can summarize this that way in all cases.\n> > \n> > Also, what does \"ineffective\" mean? If I get a cc 1 for, say, ssch, I\n> > don't expect something either as the subchannel was already status\n> > pending. \n> \n> You are right cc 1 would have been better off with\n> 'produced alternate result or status pending'\n> \n> I've tried to make this shorter (from PoP 14-2):\n> \"\"\"\n> Condition Code 0: Instruction execution produced\n> the expected or most probable result. (See “Deferred\n> Condition Code (CC)” on page 9 for a description of\n> conditions that can be encountered subsequent to\n> the presentation of condition code 0 that result in a\n> nonzero deferred condition code.)\n> Condition Code 1: Instruction execution produced\n> the alternate or second-most-probable result, or sta-\n> tus conditions were present that may or may not have\n> prevented the expected result.\n> Condition Code 2: Instruction execution was inef-\n> fective because the designated subchannel or chan-\n> nel-subsystem facility was busy with a previously\n> initiated function.\n> Condition Code 3: Instruction execution was inef-\n> fective because the designated element was not\n> operational or because some condition precluded ini-\n> tiation of the normal function.\n> \"\"\"\n> \n> Well ineffective means not-effective ;).\n\nYes :)\n\nI think the summary in the PoP is already a bit on the over-generalized\nside, and condensing it further makes it rather ineffective ;) at\nexplaining what happens. Frankly, I'd just drop this and rely on\ninterested parties referring to the PoP.\n\n> \n> > \n> >> + */\n> >> + uint32_t cc:4;\n> >> + bool pgm_chk:1; \n> > \n> > This looks weird?> \n> \n> What do you mean? Any suggestions how to do it better?\n\nTaking one bit from a bool looks odd. I'd either use a bool normally or\ntake one bit from an uint8_t.\n\n> \n> >> + uint32_t irq_code;\n> >> + } iret;\n> >> };\n> >> \n> >> extern const VMStateDescription vmstate_subch_dev; \n\n> But I guess, I was afraid of somebody blaming me for this\n> comment (such TODOs in production code are a bit strange -- what\n> does it mean: we did not bother to figure it out?).\n\nFor one, the TODO is preexisting... and we really should remember to\nfigure out if there's something better rather than just drop the\ncomment.\n\n(And I sure hope nobody is using vfio-ccw in production yet...)","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-mx07.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx07.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 3xmsYH4bGpz9s7C\n\tfor ;\n\tWed, 6 Sep 2017 02:26:43 +1000 (AEST)","from localhost ([::1]:60095 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpGgT-0003dc-PB\n\tfor incoming@patchwork.ozlabs.org; Tue, 05 Sep 2017 12:26:41 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:48279)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpGfm-0003Nl-NX\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 12:26:03 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpGfe-0004Bd-Ii\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 12:25:58 -0400","from mx1.redhat.com ([209.132.183.28]:57120)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dpGfe-0004An-AH\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 12:25:50 -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 6BF6EC07F691;\n\tTue, 5 Sep 2017 16:25:49 +0000 (UTC)","from gondolin (dhcp-192-215.str.redhat.com [10.33.192.215])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 839C36E517;\n\tTue, 5 Sep 2017 16:25:48 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 6BF6EC07F691","Date":"Tue, 5 Sep 2017 18:25:46 +0200","From":"Cornelia Huck ","To":"Halil Pasic ","Message-ID":"<20170905182546.00457332.cohuck@redhat.com>","In-Reply-To":"<7540741b-d230-e7c4-50d3-036f31997c8b@linux.vnet.ibm.com>","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-5-pasic@linux.vnet.ibm.com>\n\t<20170831115535.1e4201d3.cohuck@redhat.com>\n\t<7540741b-d230-e7c4-50d3-036f31997c8b@linux.vnet.ibm.com>","Organization":"Red Hat GmbH","MIME-Version":"1.0","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"quoted-printable","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.31]);\n\tTue, 05 Sep 2017 16:25:49 +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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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":1763708,"web_url":"http://patchwork.ozlabs.org/comment/1763708/","msgid":"","list_archive_url":null,"date":"2017-09-05T22:30:58","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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 06:25 PM, Cornelia Huck wrote:\n> On Tue, 5 Sep 2017 17:55:17 +0200\n> Halil Pasic wrote:\n> \n>> On 08/31/2017 11:55 AM, Cornelia Huck wrote:\n>>> On Wed, 30 Aug 2017 18:36:04 +0200\n>>> Halil Pasic wrote:\n>>> \n>>>> Simplify the error handling of the SSCH and RSCH handler avoiding\n>>>> arbitrary and cryptic error codes being mapped to what a subchannel is\n>>>> supposed to do. Let the code detecting the condition tell how it's to be\n>>>> handled in a less ambiguous way. It's best to handle SSCH and RSCH in\n>>>> one go as the emulation of the two shares a lot of code. \n>>>\n>>> So determining the return code at the point in time where we can\n>>> instead of trying to map to return codes and back again makes quite a\n>>> bit of sense, but I'll have to look at the rest of this. \n>>\n>>\n>> Looging forward to.\n> \n> Once I manage to find some quiet time for thinking :(\n\nI think it's the best if you ignore the rest until v2.\n\nSince we agreed that cc 3 is not the way to go and that the basic\nidea is sane, IMHO it does not make much sense to do a thorough\nreview of this any more.\n\nNot diverting valuable maintainer resources from my indirect data \naccess patch set is also a point (IDA is something I have to deliver, while\nthis is just for fun).\n \n> \n>>>> - ret = s390_ccw_cmd_request(orb, s, sch->driver_data);\n>>>> - switch (ret) {\n>>>> - /* Currently we don't update control block and just return the cc code. */\n>>>> - case 0:\n>>>> - break;\n>>>> - case -EBUSY:\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>>>> - default:\n>>>> - /* Let's make all other return codes map to cc 3. */\n>>>> - ret = -ENODEV;\n>>>> - };\n>>>> -\n>>>> - return ret;\n>>>> + s390_ccw_cmd_request(sch); \n>>>\n>>> As you change the handling anyway: Don't change this logic in prior\n>>> patches? \n>>\n>> I preserve the logic as altered by the previous patches (at least,\n>> that is the intention). This is the mapping around part which is going\n>> away if we push the handling down.\n> \n> My point is that you touch the code path twice. But we disagreed on the\n> original change anyway :)\n\nNod.\n\n> \n>>>> -int do_subchannel_work_passthrough(SubchDev *sch)\n>>>> +void do_subchannel_work_passthrough(SubchDev *sch)\n>>>> {\n>>>> - int ret;\n>>>> SCSW *s = &sch->curr_status.scsw;\n>>>> \n>>>> if (s->ctrl & SCSW_FCTL_CLEAR_FUNC) {\n>>>> /* TODO: Clear handling */\n>>>> sch_handle_clear_func(sch);\n>>>> - ret = 0;\n>>>> } else if (s->ctrl & SCSW_FCTL_HALT_FUNC) {\n>>>> /* TODO: Halt handling */\n>>>> sch_handle_halt_func(sch);\n>>>> - ret = 0;\n>>>> } else if (s->ctrl & SCSW_FCTL_START_FUNC) {\n>>>> - ret = sch_handle_start_func_passthrough(sch);\n>>>> + sch_handle_start_func_passthrough(sch);\n>>>> } else {\n>>>> /* Cannot happen. */\n>>>> - return -ENODEV;\n>>>> + sch->iret.cc = 3; \n>>>\n>>> ftcl == 0 should have been rejected already by the function handlers\n>>> here as well, shouldn't it? \n>>\n>> Which function handlers. Basically the instruction handlers set fctl\n>> and call do_subchannel_work to get the indicated work done.\n> \n> Or set. My point is that we can't get here with fctl == 0. So an assert\n> sounds better to me.\n> \nYeah, I agree assert is the way to go here.\n\n> \n>>>> diff --git a/include/hw/s390x/css.h b/include/hw/s390x/css.h\n>>>> index 5c5fe6b202..d093181a9e 100644\n>>>> --- a/include/hw/s390x/css.h\n>>>> +++ b/include/hw/s390x/css.h\n>>>> @@ -94,13 +94,31 @@ struct SubchDev {\n>>>> /* transport-provided data: */\n>>>> int (*ccw_cb) (SubchDev *, CCW1);\n>>>> void (*disable_cb)(SubchDev *);\n>>>> - int (*do_subchannel_work) (SubchDev *);\n>>>> + void (*do_subchannel_work) (SubchDev *);\n>>>> SenseId id;\n>>>> void *driver_data;\n>>>> + /* io instructions conclude according to iret */\n>>>> + struct {\n>>>> + /*\n>>>> + * General semantic of cc codes of IO instructions is (brief):\n>>>> + * 0 -- produced expected result\n>>>> + * 1 -- produced alternate result\n>>>> + * 2 -- ineffective, because busy with previously initiated function\n>>>> + * 3 -- ineffective, not operational \n>>>\n>>> I'm not sure you can summarize this that way in all cases.\n>>>\n>>> Also, what does \"ineffective\" mean? If I get a cc 1 for, say, ssch, I\n>>> don't expect something either as the subchannel was already status\n>>> pending. \n>>\n>> You are right cc 1 would have been better off with\n>> 'produced alternate result or status pending'\n>>\n>> I've tried to make this shorter (from PoP 14-2):\n>> \"\"\"\n>> Condition Code 0: Instruction execution produced\n>> the expected or most probable result. (See “Deferred\n>> Condition Code (CC)” on page 9 for a description of\n>> conditions that can be encountered subsequent to\n>> the presentation of condition code 0 that result in a\n>> nonzero deferred condition code.)\n>> Condition Code 1: Instruction execution produced\n>> the alternate or second-most-probable result, or sta-\n>> tus conditions were present that may or may not have\n>> prevented the expected result.\n>> Condition Code 2: Instruction execution was inef-\n>> fective because the designated subchannel or chan-\n>> nel-subsystem facility was busy with a previously\n>> initiated function.\n>> Condition Code 3: Instruction execution was inef-\n>> fective because the designated element was not\n>> operational or because some condition precluded ini-\n>> tiation of the normal function.\n>> \"\"\"\n>>\n>> Well ineffective means not-effective ;).\n> \n> Yes :)\n> \n> I think the summary in the PoP is already a bit on the over-generalized\n> side, and condensing it further makes it rather ineffective ;) at\n> explaining what happens. Frankly, I'd just drop this and rely on\n> interested parties referring to the PoP.\n> \n\nThat's what I did in the first place, but then Janosch complained.\nI will meditate on this (having some sort of explanation is helpful\nand I think cc 0 2 and 3 are actually quite OK).\n\n>>\n>>> \n>>>> + */\n>>>> + uint32_t cc:4;\n>>>> + bool pgm_chk:1; \n>>>\n>>> This looks weird?> \n>>\n>> What do you mean? Any suggestions how to do it better?\n> \n> Taking one bit from a bool looks odd. I'd either use a bool normally or\n> take one bit from an uint8_t.\n> \n\nI have to think about this.\n\n>> \n>>>> + uint32_t irq_code;\n>>>> + } iret;\n>>>> };\n>>>> \n>>>> extern const VMStateDescription vmstate_subch_dev; \n> \n>> But I guess, I was afraid of somebody blaming me for this\n>> comment (such TODOs in production code are a bit strange -- what\n>> does it mean: we did not bother to figure it out?).\n> \n> For one, the TODO is preexisting... and we really should remember to\n> figure out if there's something better rather than just drop the\n> comment.\n> \n> (And I sure hope nobody is using vfio-ccw in production yet...)\n>\nSince blame says the TODO has been around since 2017-05-17\nlet me have a critical look at it.\n\nAt a first glance I would say addressing exception for SSCH\nis not what we want: the only possibility I see for address\nexception for SSCH is due to the ORB address. But if that's\nthe case we will never reach the code in question. So I suppose\nwe can do better.\n\nAdding Ren. @Ren: Do you agree with my analysis. If you do,\nI could come up with a proposal what to do -- after some reading.\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 3xn1fL0MQ9z9sNq\n\tfor ;\n\tWed, 6 Sep 2017 08:31:36 +1000 (AEST)","from localhost ([::1]:33406 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpMNZ-0004pe-VA\n\tfor incoming@patchwork.ozlabs.org; Tue, 05 Sep 2017 18:31:33 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:54020)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpMNC-0004pG-67\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 18:31:15 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpMN6-0001OW-US\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 18:31:10 -0400","from mx0b-001b2d01.pphosted.com ([148.163.158.5]:47506\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 1dpMN6-0001OG-Oy\n\tfor qemu-devel@nongnu.org; Tue, 05 Sep 2017 18:31:04 -0400","from pps.filterd (m0098419.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv85MSgZv131992\n\tfor ; Tue, 5 Sep 2017 18:31:02 -0400","from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2ct32mmvk4-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Tue, 05 Sep 2017 18:31:02 -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 23:31:01 +0100","from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194)\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 23:30:59 +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 v85MUw0l22872106; Tue, 5 Sep 2017 22:30:58 GMT","from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 269BF52041;\n\tTue, 5 Sep 2017 22:26:17 +0100 (BST)","from oc3836556865.ibm.com (unknown [9.145.53.241])\n\tby d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id 8ADD15203F; \n\tTue, 5 Sep 2017 22:26:16 +0100 (BST)"],"To":"Cornelia Huck ,\n\tXiao Feng Ren ","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-5-pasic@linux.vnet.ibm.com>\n\t<20170831115535.1e4201d3.cohuck@redhat.com>\n\t<7540741b-d230-e7c4-50d3-036f31997c8b@linux.vnet.ibm.com>\n\t<20170905182546.00457332.cohuck@redhat.com>","From":"Halil Pasic ","Date":"Wed, 6 Sep 2017 00:30:58 +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":"<20170905182546.00457332.cohuck@redhat.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","X-TM-AS-GCONF":"00","x-cbid":"17090522-0020-0000-0000-000003B3D97F","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17090522-0021-0000-0000-000042444484","Message-Id":"","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-05_10:, , 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-1709050331","Content-Transfer-Encoding":"quoted-printable","X-MIME-Autoconverted":"from 8bit to quoted-printable by\n\tmx0b-001b2d01.pphosted.com id v85MSgZv131992","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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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":1763806,"web_url":"http://patchwork.ozlabs.org/comment/1763806/","msgid":"<20170906043108.GY31680@bjsdjshi@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-06T04:31:08","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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-06 00:30:58 +0200]:\n\n[...]\n\n> > \n> >> But I guess, I was afraid of somebody blaming me for this\n> >> comment (such TODOs in production code are a bit strange -- what\n> >> does it mean: we did not bother to figure it out?).\n> > \n> > For one, the TODO is preexisting... and we really should remember to\n> > figure out if there's something better rather than just drop the\n> > comment.\n> > \n> > (And I sure hope nobody is using vfio-ccw in production yet...)\n> >\n> Since blame says the TODO has been around since 2017-05-17\n> let me have a critical look at it.\n> \n> At a first glance I would say addressing exception for SSCH\n> is not what we want: the only possibility I see for address\n> exception for SSCH is due to the ORB address. But if that's\n> the case we will never reach the code in question.\nAgree.\n\n> So I suppose we can do better.\nAs the comment said, I'm (still) in the state of 'wondering'.\n\n> \n> Adding Ren. @Ren: Do you agree with my analysis. If you do,\n> I could come up with a proposal what to do -- after some reading.\nIf you have a better idea, and time, why not? ;)\n\n> \n> Regards,\n> Halil","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 3xn9f65N93z9sNV\n\tfor ;\n\tWed, 6 Sep 2017 14:31:56 +1000 (AEST)","from localhost ([::1]:33972 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpS0I-0002SU-4p\n\tfor incoming@patchwork.ozlabs.org; Wed, 06 Sep 2017 00:31:54 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:56897)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpRzx-0002SG-NO\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 00:31:34 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpRzt-0000q0-MQ\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 00:31:33 -0400","from mx0b-001b2d01.pphosted.com ([148.163.158.5]:46775\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 1dpRzt-0000nH-GA\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 00:31:29 -0400","from pps.filterd (m0098413.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv864SgWD091303\n\tfor ; Wed, 6 Sep 2017 00:31:27 -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 2ct3hgvj2f-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Wed, 06 Sep 2017 00:31:27 -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 00:31:27 -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 00:31:11 -0400","from b01ledav001.gho.pok.ibm.com (b01ledav001.gho.pok.ibm.com\n\t[9.57.199.106])\n\tby b01cxnp22034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP\n\tid v864Uxas23592976; Wed, 6 Sep 2017 04:31:10 GMT","from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 016ED2804A;\n\tWed, 6 Sep 2017 00:31:04 -0400 (EDT)","from localhost (unknown [9.115.112.23])\n\tby b01ledav001.gho.pok.ibm.com (Postfix) with ESMTP id 2D5A42803D;\n\tWed, 6 Sep 2017 00:31:02 -0400 (EDT)"],"Date":"Wed, 6 Sep 2017 12:31:08 +0800","From":"Dong Jia Shi ","To":"Halil Pasic ","Mail-Followup-To":"Halil Pasic ,\n\tCornelia Huck ,\n\tXiao Feng Ren ,\n\tDong Jia Shi ,\n\tPierre Morel , qemu-devel@nongnu.org","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-5-pasic@linux.vnet.ibm.com>\n\t<20170831115535.1e4201d3.cohuck@redhat.com>\n\t<7540741b-d230-e7c4-50d3-036f31997c8b@linux.vnet.ibm.com>\n\t<20170905182546.00457332.cohuck@redhat.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","Organization":"(IBM CSL)","X-URL":"http://ibm.com/","User-Agent":"Mutt/1.5.21 (2010-09-15)","X-TM-AS-GCONF":"00","x-cbid":"17090604-0044-0000-0000-000003888FDE","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007675; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000226; SDB=6.00912908; UDB=6.00458135;\n\tIPR=6.00693170; \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.00017026;\n\tXFM=3.00000015; UTC=2017-09-06 04:31:26","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17090604-0045-0000-0000-000007B6AAEE","Message-Id":"<20170906043108.GY31680@bjsdjshi@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-06_01:, , 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-1709060056","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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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 ,\n\tXiao Feng Ren , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1764061,"web_url":"http://patchwork.ozlabs.org/comment/1764061/","msgid":"<8946b1ec-4d14-c953-deab-aaded7cd2c9d@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-06T12:25:13","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","submitter":{"id":68297,"url":"http://patchwork.ozlabs.org/api/people/68297/","name":"Halil Pasic","email":"pasic@linux.vnet.ibm.com"},"content":"On 09/06/2017 06:31 AM, Dong Jia Shi wrote:\n> * Halil Pasic [2017-09-06 00:30:58 +0200]:\n> \n> [...]\n> \n>>>\n>>>> But I guess, I was afraid of somebody blaming me for this\n>>>> comment (such TODOs in production code are a bit strange -- what\n>>>> does it mean: we did not bother to figure it out?).\n>>>\n>>> For one, the TODO is preexisting... and we really should remember to\n>>> figure out if there's something better rather than just drop the\n>>> comment.\n>>>\n>>> (And I sure hope nobody is using vfio-ccw in production yet...)\n>>>\n>> Since blame says the TODO has been around since 2017-05-17\n>> let me have a critical look at it.\n>>\n>> At a first glance I would say addressing exception for SSCH\n>> is not what we want: the only possibility I see for address\n>> exception for SSCH is due to the ORB address. But if that's\n>> the case we will never reach the code in question.\n> Agree.\n> \n>> So I suppose we can do better.\n> As the comment said, I'm (still) in the state of 'wondering'.\n> \n>>\n>> Adding Ren. @Ren: Do you agree with my analysis. If you do,\n>> I could come up with a proposal what to do -- after some reading.\n> If you have a better idea, and time, why not? ;)\n> \n\nWe have basically two possibilities/options which ask for different\nhandling:\n1) EFAULT is due to a bug in the vfio-ccw implementation\n(can be QEMU or kernel).\n2) EFAULT is due to buggy channel program.\n\nOption 2) is basically to be handled with a channel-program check and\nsetting primary secondary and alert status. For reference see PoP page\n15-59 (\"Designation of Storage Area\"). An exception may be an invalid\nchannel program address in the ORB. There the channel-program check ain't\nexplicitly stated (although) I would expect one. It may be implied by the\nthings on page 15-59 though.\n\nOption 1) is however very similar to other we have figured out that the\nimplementation is broken situations and should be handled consequently.\nThe current state of the discussion is with a unit exception.\n\nDoes that make sense?\n\nNow, Dong Jia, I need your help to figure out do we have option 1 or\noption 2 here? After quick look at the kernel code, it appears to me that\nI've seen both option 1 and option 2 (I'm afraid) -- but my assessment\nwas really very superficial.\n\nI would expect option 2 to be handled differently (kernel provides the\nSCSW) though.\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 3xnN8r4MGfz9s03\n\tfor ;\n\tWed, 6 Sep 2017 22:25:47 +1000 (AEST)","from localhost ([::1]:35971 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpZOq-00024O-SV\n\tfor incoming@patchwork.ozlabs.org; Wed, 06 Sep 2017 08:25:44 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:44427)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpZOV-000245-S6\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 08:25:24 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpZOS-0000l3-Np\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 08:25:23 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:36664)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dpZOS-0000kQ-Eq\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 08:25:20 -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\tv86COATT127379\n\tfor ; Wed, 6 Sep 2017 08:25:18 -0400","from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2ctcd5dt6v-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Wed, 06 Sep 2017 08:25:18 -0400","from localhost\n\tby e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tWed, 6 Sep 2017 13:25:16 +0100","from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197)\n\tby e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tWed, 6 Sep 2017 13:25:14 +0100","from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com\n\t[9.149.105.62])\n\tby b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v86CPEYl19988604; Wed, 6 Sep 2017 12:25:14 GMT","from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 8BD1CAE04D;\n\tWed, 6 Sep 2017 13:20:29 +0100 (BST)","from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 3FF5FAE045;\n\tWed, 6 Sep 2017 13:20:29 +0100 (BST)","from oc3836556865.ibm.com (unknown [9.152.224.207])\n\tby d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP;\n\tWed, 6 Sep 2017 13:20:29 +0100 (BST)"],"To":"Cornelia Huck ,\n\tXiao Feng Ren ,\n\tDong Jia Shi ,\n\tPierre Morel , qemu-devel@nongnu.org","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-5-pasic@linux.vnet.ibm.com>\n\t<20170831115535.1e4201d3.cohuck@redhat.com>\n\t<7540741b-d230-e7c4-50d3-036f31997c8b@linux.vnet.ibm.com>\n\t<20170905182546.00457332.cohuck@redhat.com>\n\t\n\t<20170906043108.GY31680@bjsdjshi@linux.vnet.ibm.com>","From":"Halil Pasic ","Date":"Wed, 6 Sep 2017 14:25:13 +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":"<20170906043108.GY31680@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":"17090612-0040-0000-0000-000003D6045D","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17090612-0041-0000-0000-000025D68C27","Message-Id":"<8946b1ec-4d14-c953-deab-aaded7cd2c9d@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-06_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-1709060171","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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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":1764150,"web_url":"http://patchwork.ozlabs.org/comment/1764150/","msgid":"<20170906162019.45eeec4a.cohuck@redhat.com>","list_archive_url":null,"date":"2017-09-06T14:20:19","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","submitter":{"id":71914,"url":"http://patchwork.ozlabs.org/api/people/71914/","name":"Cornelia Huck","email":"cohuck@redhat.com"},"content":"On Wed, 6 Sep 2017 14:25:13 +0200\nHalil Pasic wrote:\n\n> We have basically two possibilities/options which ask for different\n> handling:\n> 1) EFAULT is due to a bug in the vfio-ccw implementation\n> (can be QEMU or kernel).\n> 2) EFAULT is due to buggy channel program.\n> \n> Option 2) is basically to be handled with a channel-program check and\n> setting primary secondary and alert status. For reference see PoP page\n> 15-59 (\"Designation of Storage Area\"). An exception may be an invalid\n> channel program address in the ORB. There the channel-program check ain't\n> explicitly stated (although) I would expect one. It may be implied by the\n> things on page 15-59 though.\n> \n> Option 1) is however very similar to other we have figured out that the\n> implementation is broken situations and should be handled consequently.\n> The current state of the discussion is with a unit exception.\n> \n> Does that make sense?\n\nI think the situation is slightly different here, though. For the orb\nflags, we reject something out of hand because we have not implemented\nit, and for that, unit exception sounds like a good fit. Processing\nerrors, however, are more similar to errors in the hardware, and as\nsuch can probably be reported via something like equipment check.\n\n> \n> Now, Dong Jia, I need your help to figure out do we have option 1 or\n> option 2 here? After quick look at the kernel code, it appears to me that\n> I've seen both option 1 and option 2 (I'm afraid) -- but my assessment\n> was really very superficial.\n> \n> I would expect option 2 to be handled differently (kernel provides the\n> SCSW) though.\n> \n> Regards,\n> Halil\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-mx07.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx07.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 3xnQvk31BFz9t4t\n\tfor ;\n\tThu, 7 Sep 2017 00:29:38 +1000 (AEST)","from localhost ([::1]:36414 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpbKi-0001Dr-G9\n\tfor incoming@patchwork.ozlabs.org; Wed, 06 Sep 2017 10:29:36 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:56767)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpbBs-0002um-MS\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 10:20:32 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpbBn-0001cQ-Ub\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 10:20:28 -0400","from mx1.redhat.com ([209.132.183.28]:60182)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dpbBn-0001cI-OG\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 10:20:23 -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 BC9BFC047B6A;\n\tWed, 6 Sep 2017 14:20:22 +0000 (UTC)","from gondolin (dhcp-192-215.str.redhat.com [10.33.192.215])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id D764E7D3F3;\n\tWed, 6 Sep 2017 14:20:21 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com BC9BFC047B6A","Date":"Wed, 6 Sep 2017 16:20:19 +0200","From":"Cornelia Huck ","To":"Halil Pasic ","Message-ID":"<20170906162019.45eeec4a.cohuck@redhat.com>","In-Reply-To":"<8946b1ec-4d14-c953-deab-aaded7cd2c9d@linux.vnet.ibm.com>","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-5-pasic@linux.vnet.ibm.com>\n\t<20170831115535.1e4201d3.cohuck@redhat.com>\n\t<7540741b-d230-e7c4-50d3-036f31997c8b@linux.vnet.ibm.com>\n\t<20170905182546.00457332.cohuck@redhat.com>\n\t\n\t<20170906043108.GY31680@bjsdjshi@linux.vnet.ibm.com>\n\t<8946b1ec-4d14-c953-deab-aaded7cd2c9d@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.14","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.31]);\n\tWed, 06 Sep 2017 14:20:22 +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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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\tXiao Feng Ren , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1764164,"web_url":"http://patchwork.ozlabs.org/comment/1764164/","msgid":"","list_archive_url":null,"date":"2017-09-06T14:43:42","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","submitter":{"id":68297,"url":"http://patchwork.ozlabs.org/api/people/68297/","name":"Halil Pasic","email":"pasic@linux.vnet.ibm.com"},"content":"On 09/06/2017 04:20 PM, Cornelia Huck wrote:\n> On Wed, 6 Sep 2017 14:25:13 +0200\n> Halil Pasic wrote:\n> \n>> We have basically two possibilities/options which ask for different\n>> handling:\n>> 1) EFAULT is due to a bug in the vfio-ccw implementation\n>> (can be QEMU or kernel).\n>> 2) EFAULT is due to buggy channel program.\n>>\n>> Option 2) is basically to be handled with a channel-program check and\n>> setting primary secondary and alert status. For reference see PoP page\n>> 15-59 (\"Designation of Storage Area\"). An exception may be an invalid\n>> channel program address in the ORB. There the channel-program check ain't\n>> explicitly stated (although) I would expect one. It may be implied by the\n>> things on page 15-59 though.\n>>\n>> Option 1) is however very similar to other we have figured out that the\n>> implementation is broken situations and should be handled consequently.\n>> The current state of the discussion is with a unit exception.\n>>\n>> Does that make sense?\n> \n> I think the situation is slightly different here, though. For the orb\n> flags, we reject something out of hand because we have not implemented\n> it, and for that, unit exception sounds like a good fit. Processing\n> errors, however, are more similar to errors in the hardware, and as\n> such can probably be reported via something like equipment check.\n> \n\nNoted. Let's see what Dong Jia has to say, before we continuing a\ndiscussion on something (option 1) what may be irrelevant anyway.\n\n>>\n>> Now, Dong Jia, I need your help to figure out do we have option 1 or\n>> option 2 here? After quick look at the kernel code, it appears to me that\n>> I've seen both option 1 and option 2 (I'm afraid) -- but my assessment\n>> was really very superficial.\n>>\n>> I would expect option 2 to be handled differently (kernel provides the\n>> SCSW) though.\n>>\n>> Regards,\n>> Halil\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 3xnRDq39SVz9t4t\n\tfor ;\n\tThu, 7 Sep 2017 00:44:27 +1000 (AEST)","from localhost ([::1]:36508 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpbZ3-0002sx-Fo\n\tfor incoming@patchwork.ozlabs.org; Wed, 06 Sep 2017 10:44:25 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:38257)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpbYY-0002r6-RY\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 10:43:55 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpbYV-00058I-Ii\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 10:43:54 -0400","from mx0b-001b2d01.pphosted.com ([148.163.158.5]:47329\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 1dpbYV-00057m-CN\n\tfor qemu-devel@nongnu.org; Wed, 06 Sep 2017 10:43:51 -0400","from pps.filterd (m0098419.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv86EgMVM031802\n\tfor ; Wed, 6 Sep 2017 10:43:50 -0400","from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2cthjqeaqv-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Wed, 06 Sep 2017 10:43:50 -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\tWed, 6 Sep 2017 15:43:46 +0100","from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196)\n\tby e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tWed, 6 Sep 2017 15:43:43 +0100","from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com\n\t[9.149.105.62])\n\tby b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v86EhhEo26869808; Wed, 6 Sep 2017 14:43:43 GMT","from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 920C8AE045;\n\tWed, 6 Sep 2017 15:38:58 +0100 (BST)","from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 3F111AE04D;\n\tWed, 6 Sep 2017 15:38:58 +0100 (BST)","from oc3836556865.ibm.com (unknown [9.152.224.207])\n\tby d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP;\n\tWed, 6 Sep 2017 15:38:58 +0100 (BST)"],"To":"Cornelia Huck ","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-5-pasic@linux.vnet.ibm.com>\n\t<20170831115535.1e4201d3.cohuck@redhat.com>\n\t<7540741b-d230-e7c4-50d3-036f31997c8b@linux.vnet.ibm.com>\n\t<20170905182546.00457332.cohuck@redhat.com>\n\t\n\t<20170906043108.GY31680@bjsdjshi@linux.vnet.ibm.com>\n\t<8946b1ec-4d14-c953-deab-aaded7cd2c9d@linux.vnet.ibm.com>\n\t<20170906162019.45eeec4a.cohuck@redhat.com>","From":"Halil Pasic ","Date":"Wed, 6 Sep 2017 16:43:42 +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":"<20170906162019.45eeec4a.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":"17090614-0012-0000-0000-0000057602FD","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17090614-0013-0000-0000-000018EF0306","Message-Id":"","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-06_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-1709060206","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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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\tXiao Feng Ren , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1764597,"web_url":"http://patchwork.ozlabs.org/comment/1764597/","msgid":"<20170907085831.GF31680@bjsdjshi@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-07T08:58:31","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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-06 16:43:42 +0200]:\n\n> \n> \n> On 09/06/2017 04:20 PM, Cornelia Huck wrote:\n> > On Wed, 6 Sep 2017 14:25:13 +0200\n> > Halil Pasic wrote:\n> > \n> >> We have basically two possibilities/options which ask for different\n> >> handling:\n> >> 1) EFAULT is due to a bug in the vfio-ccw implementation\n> >> (can be QEMU or kernel).\n> >> 2) EFAULT is due to buggy channel program.\n> >>\n> >> Option 2) is basically to be handled with a channel-program check and\n> >> setting primary secondary and alert status. For reference see PoP page\n> >> 15-59 (\"Designation of Storage Area\"). An exception may be an invalid\n> >> channel program address in the ORB. There the channel-program check ain't\n> >> explicitly stated (although) I would expect one. It may be implied by the\n> >> things on page 15-59 though.\n> >>\n> >> Option 1) is however very similar to other we have figured out that the\n> >> implementation is broken situations and should be handled consequently.\n> >> The current state of the discussion is with a unit exception.\n> >>\n> >> Does that make sense?\n> > \n> > I think the situation is slightly different here, though. For the orb\n> > flags, we reject something out of hand because we have not implemented\n> > it, and for that, unit exception sounds like a good fit. Processing\n> > errors, however, are more similar to errors in the hardware, and as\n> > such can probably be reported via something like equipment check.\n> > \n> \n> Noted. Let's see what Dong Jia has to say, before we continuing a\n> discussion on something (option 1) what may be irrelevant anyway.\n> \n> >>\n> >> Now, Dong Jia, I need your help to figure out do we have option 1 or\n> >> option 2 here? After quick look at the kernel code, it appears to me that\n> >> I've seen both option 1 and option 2 (I'm afraid) -- but my assessment\n> >> was really very superficial.\nThere are three cases (all in the kernel) that generate a -EFAULT ret\ncode:\na. vfio_ccw_mdev_write: copy_from_user() fails.\n This is option 1.\n\nb. ccwchain_fetch_tic\n It's mostly likely that the vfio-ccw driver processed the ccw chains\n wrongly. (Actually I can not think of any other reason.)\n This is option 1.\n\nc. ccwchain_fetch_idal\n When we find that an IDAW contents an invalid address\n This is option 2.\n\n> >>\n> >> I would expect option 2 to be handled differently (kernel provides the\n> >> SCSW) though.\n> >>\n> >> Regards,\n> >> Halil\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 3xnvXP36YFz9sRV\n\tfor ;\n\tThu, 7 Sep 2017 18:59:32 +1000 (AEST)","from localhost ([::1]:39423 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpseo-0000Es-4m\n\tfor incoming@patchwork.ozlabs.org; Thu, 07 Sep 2017 04:59:30 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:48891)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpse3-0000AD-A3\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 04:58:48 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpse0-0001RA-8A\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 04:58:43 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:60094)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dpsdz-0001NK-Vy\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 04:58:40 -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\tv878v5Ve007326\n\tfor ; Thu, 7 Sep 2017 04:58:38 -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 2cu21tbb0f-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Thu, 07 Sep 2017 04:58:38 -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:58:37 -0400","from b01cxnp23034.gho.pok.ibm.com (9.57.198.29)\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:58:34 -0400","from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com\n\t[9.57.199.110])\n\tby b01cxnp23034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP\n\tid v878wYM033751256; Thu, 7 Sep 2017 08:58:34 GMT","from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 19B56AE03C;\n\tThu, 7 Sep 2017 04:59:01 -0400 (EDT)","from localhost (unknown [9.115.112.23])\n\tby b01ledav005.gho.pok.ibm.com (Postfix) with ESMTP id 4B21BAE04B;\n\tThu, 7 Sep 2017 04:59:00 -0400 (EDT)"],"Date":"Thu, 7 Sep 2017 16:58:31 +0800","From":"Dong Jia Shi ","To":"Halil Pasic ","Mail-Followup-To":"Halil Pasic ,\n\tCornelia Huck ,\n\tDong Jia Shi ,\n\tPierre Morel ,\n\tXiao Feng Ren , qemu-devel@nongnu.org","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-5-pasic@linux.vnet.ibm.com>\n\t<20170831115535.1e4201d3.cohuck@redhat.com>\n\t<7540741b-d230-e7c4-50d3-036f31997c8b@linux.vnet.ibm.com>\n\t<20170905182546.00457332.cohuck@redhat.com>\n\t\n\t<20170906043108.GY31680@bjsdjshi@linux.vnet.ibm.com>\n\t<8946b1ec-4d14-c953-deab-aaded7cd2c9d@linux.vnet.ibm.com>\n\t<20170906162019.45eeec4a.cohuck@redhat.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","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-0000038A9ED7","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007682; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000226; SDB=6.00913477; UDB=6.00458475;\n\tIPR=6.00693735; \n\tBA=6.00005575; 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:58:35","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17090708-0045-0000-0000-000007B99EF0","Message-Id":"<20170907085831.GF31680@bjsdjshi@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-07_06:, , 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-1709070132","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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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 ,\n\tXiao Feng Ren , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1764635,"web_url":"http://patchwork.ozlabs.org/comment/1764635/","msgid":"<2aa8cf98-c331-fe5a-0a7e-1a553c6c5054@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-07T10:15:05","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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:58 AM, Dong Jia Shi wrote:\n> * Halil Pasic [2017-09-06 16:43:42 +0200]:\n> \n>>\n>>\n>> On 09/06/2017 04:20 PM, Cornelia Huck wrote:\n>>> On Wed, 6 Sep 2017 14:25:13 +0200\n>>> Halil Pasic wrote:\n>>>\n>>>> We have basically two possibilities/options which ask for different\n>>>> handling:\n>>>> 1) EFAULT is due to a bug in the vfio-ccw implementation\n>>>> (can be QEMU or kernel).\n>>>> 2) EFAULT is due to buggy channel program.\n>>>>\n>>>> Option 2) is basically to be handled with a channel-program check and\n>>>> setting primary secondary and alert status. For reference see PoP page\n>>>> 15-59 (\"Designation of Storage Area\"). An exception may be an invalid\n>>>> channel program address in the ORB. There the channel-program check ain't\n>>>> explicitly stated (although) I would expect one. It may be implied by the\n>>>> things on page 15-59 though.\n>>>>\n>>>> Option 1) is however very similar to other we have figured out that the\n>>>> implementation is broken situations and should be handled consequently.\n>>>> The current state of the discussion is with a unit exception.\n>>>>\n>>>> Does that make sense?\n>>>\n>>> I think the situation is slightly different here, though. For the orb\n>>> flags, we reject something out of hand because we have not implemented\n>>> it, and for that, unit exception sounds like a good fit. Processing\n>>> errors, however, are more similar to errors in the hardware, and as\n>>> such can probably be reported via something like equipment check.\n>>>\n>>\n>> Noted. Let's see what Dong Jia has to say, before we continuing a\n>> discussion on something (option 1) what may be irrelevant anyway.\n>>\n>>>>\n>>>> Now, Dong Jia, I need your help to figure out do we have option 1 or\n>>>> option 2 here? After quick look at the kernel code, it appears to me that\n>>>> I've seen both option 1 and option 2 (I'm afraid) -- but my assessment\n>>>> was really very superficial.\n> There are three cases (all in the kernel) that generate a -EFAULT ret\n> code:\n> a. vfio_ccw_mdev_write: copy_from_user() fails.\n> This is option 1.\n> \n> b. ccwchain_fetch_tic\n> It's mostly likely that the vfio-ccw driver processed the ccw chains\n> wrongly. (Actually I can not think of any other reason.)\n> This is option 1.\n> \n> c. ccwchain_fetch_idal\n> When we find that an IDAW contents an invalid address\n> This is option 2.\n> \n\nSo my fear was justified. If we can't tell if its option 1 or 2, and\ncurrently we can't, I would say we shall trust our infrastructure and\nblame the channel program: that boils down to channel-program check.\nThat's my assessment with the kernel driver being as-is.\n\nIf we are willing to change the vfio-ccw kernel driver, then generating\na response to option 2 conditions in the kernel (basically an SCSW) is\nIMHO better. For instance we can do SCSW.cpa and SCWS.count properly.\nAFAIR we are not allowed to present conditions that logically did not\nhappen (yet) -- for instance if we have per-fetched a bad CCW address\nbut the given ccw did not become active yet.\n\nIf we handle option 2 via a different channel (SCWS instead of return\ncode) then we could happily do the proper handling for option 1 here.\n\nSo Dong Jia the call is again yours to make!\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 3xnxDB697Jz9t2c\n\tfor ;\n\tThu, 7 Sep 2017 20:15:36 +1000 (AEST)","from localhost ([::1]:39669 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dptqQ-0000Pm-Cw\n\tfor incoming@patchwork.ozlabs.org; Thu, 07 Sep 2017 06:15:34 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:49264)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dptq8-0000Pf-K0\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 06:15:17 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dptq4-0007nz-Gl\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 06:15:16 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:44774)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dptq4-0007nc-82\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 06:15:12 -0400","from pps.filterd (m0098404.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv87AE1xZ042654\n\tfor ; Thu, 7 Sep 2017 06:15:10 -0400","from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2cu1f105ym-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Thu, 07 Sep 2017 06:15:10 -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, 7 Sep 2017 11:15:08 +0100","from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195)\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, 7 Sep 2017 11:15:06 +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 v87AF5tg31654094; Thu, 7 Sep 2017 10:15:05 GMT","from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id DD0BA52047;\n\tThu, 7 Sep 2017 10:10:21 +0100 (BST)","from oc3836556865.ibm.com (unknown [9.152.224.207])\n\tby d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id 69D765203F; \n\tThu, 7 Sep 2017 10:10:21 +0100 (BST)"],"To":"Cornelia Huck ,\n\tDong Jia Shi ,\n\tPierre Morel ,\n\tXiao Feng Ren , qemu-devel@nongnu.org","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-5-pasic@linux.vnet.ibm.com>\n\t<20170831115535.1e4201d3.cohuck@redhat.com>\n\t<7540741b-d230-e7c4-50d3-036f31997c8b@linux.vnet.ibm.com>\n\t<20170905182546.00457332.cohuck@redhat.com>\n\t\n\t<20170906043108.GY31680@bjsdjshi@linux.vnet.ibm.com>\n\t<8946b1ec-4d14-c953-deab-aaded7cd2c9d@linux.vnet.ibm.com>\n\t<20170906162019.45eeec4a.cohuck@redhat.com>\n\t\n\t<20170907085831.GF31680@bjsdjshi@linux.vnet.ibm.com>","From":"Halil Pasic ","Date":"Thu, 7 Sep 2017 12:15: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":"<20170907085831.GF31680@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":"17090710-0012-0000-0000-000005773EA2","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17090710-0013-0000-0000-000018F040EE","Message-Id":"<2aa8cf98-c331-fe5a-0a7e-1a553c6c5054@linux.vnet.ibm.com>","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-1709070151","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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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":1764639,"web_url":"http://patchwork.ozlabs.org/comment/1764639/","msgid":"<20170907122400.5b2e3faa.cohuck@redhat.com>","list_archive_url":null,"date":"2017-09-07T10:24:00","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","submitter":{"id":71914,"url":"http://patchwork.ozlabs.org/api/people/71914/","name":"Cornelia Huck","email":"cohuck@redhat.com"},"content":"On Thu, 7 Sep 2017 16:58:31 +0800\nDong Jia Shi wrote:\n\n> * Halil Pasic [2017-09-06 16:43:42 +0200]:\n> \n> > \n> > \n> > On 09/06/2017 04:20 PM, Cornelia Huck wrote: \n> > > On Wed, 6 Sep 2017 14:25:13 +0200\n> > > Halil Pasic wrote:\n> > > \n> > >> We have basically two possibilities/options which ask for different\n> > >> handling:\n> > >> 1) EFAULT is due to a bug in the vfio-ccw implementation\n> > >> (can be QEMU or kernel).\n> > >> 2) EFAULT is due to buggy channel program.\n> > >>\n> > >> Option 2) is basically to be handled with a channel-program check and\n> > >> setting primary secondary and alert status. For reference see PoP page\n> > >> 15-59 (\"Designation of Storage Area\"). An exception may be an invalid\n> > >> channel program address in the ORB. There the channel-program check ain't\n> > >> explicitly stated (although) I would expect one. It may be implied by the\n> > >> things on page 15-59 though.\n> > >>\n> > >> Option 1) is however very similar to other we have figured out that the\n> > >> implementation is broken situations and should be handled consequently.\n> > >> The current state of the discussion is with a unit exception.\n> > >>\n> > >> Does that make sense? \n> > > \n> > > I think the situation is slightly different here, though. For the orb\n> > > flags, we reject something out of hand because we have not implemented\n> > > it, and for that, unit exception sounds like a good fit. Processing\n> > > errors, however, are more similar to errors in the hardware, and as\n> > > such can probably be reported via something like equipment check.\n> > > \n> > \n> > Noted. Let's see what Dong Jia has to say, before we continuing a\n> > discussion on something (option 1) what may be irrelevant anyway.\n> > \n> > >>\n> > >> Now, Dong Jia, I need your help to figure out do we have option 1 or\n> > >> option 2 here? After quick look at the kernel code, it appears to me that\n> > >> I've seen both option 1 and option 2 (I'm afraid) -- but my assessment\n> > >> was really very superficial. \n> There are three cases (all in the kernel) that generate a -EFAULT ret\n> code:\n> a. vfio_ccw_mdev_write: copy_from_user() fails.\n> This is option 1.\n> \n> b. ccwchain_fetch_tic\n> It's mostly likely that the vfio-ccw driver processed the ccw chains\n> wrongly. (Actually I can not think of any other reason.)\n\nMe neither, I'd consider hitting this a bug in the implementation.\n\n> This is option 1.\n> \n> c. ccwchain_fetch_idal\n> When we find that an IDAW contents an invalid address\n> This is option 2.\n> \n> > >>\n> > >> I would expect option 2 to be handled differently (kernel provides the\n> > >> SCSW) though.\n\nSo we would do an equipment check for the first two (\"equipment\", i.e.\nthe software, is malfunctioning) and use a more appropriate way for the\nmalformed idaw?","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-mx07.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx07.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 3xnxbb4cd3z9t2M\n\tfor ;\n\tThu, 7 Sep 2017 20:32:26 +1000 (AEST)","from localhost ([::1]:39706 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpu6g-0004qr-GU\n\tfor incoming@patchwork.ozlabs.org; Thu, 07 Sep 2017 06:32:22 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:54735)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpu6F-0004qi-DV\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 06:31:56 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpu6C-0007xC-9u\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 06:31:55 -0400","from mx1.redhat.com ([209.132.183.28]:57980)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dpu6C-0007u8-12\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 06:31:52 -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 6F7AEC047B62;\n\tThu, 7 Sep 2017 10:24:03 +0000 (UTC)","from gondolin (dhcp-192-215.str.redhat.com [10.33.192.215])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id 6313C6060C;\n\tThu, 7 Sep 2017 10:24:02 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 6F7AEC047B62","Date":"Thu, 7 Sep 2017 12:24:00 +0200","From":"Cornelia Huck ","To":"Dong Jia Shi ","Message-ID":"<20170907122400.5b2e3faa.cohuck@redhat.com>","In-Reply-To":"<20170907085831.GF31680@bjsdjshi@linux.vnet.ibm.com>","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-5-pasic@linux.vnet.ibm.com>\n\t<20170831115535.1e4201d3.cohuck@redhat.com>\n\t<7540741b-d230-e7c4-50d3-036f31997c8b@linux.vnet.ibm.com>\n\t<20170905182546.00457332.cohuck@redhat.com>\n\t\n\t<20170906043108.GY31680@bjsdjshi@linux.vnet.ibm.com>\n\t<8946b1ec-4d14-c953-deab-aaded7cd2c9d@linux.vnet.ibm.com>\n\t<20170906162019.45eeec4a.cohuck@redhat.com>\n\t\n\t<20170907085831.GF31680@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.13","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.31]);\n\tThu, 07 Sep 2017 10:24:03 +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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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\tXiao Feng Ren , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1764664,"web_url":"http://patchwork.ozlabs.org/comment/1764664/","msgid":"<27b2addf-0d1c-81d7-1e82-1a8cdac70231@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-07T11:32:41","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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 12:24 PM, Cornelia Huck wrote:\n> On Thu, 7 Sep 2017 16:58:31 +0800\n> Dong Jia Shi wrote:\n> \n>> * Halil Pasic [2017-09-06 16:43:42 +0200]:\n>>\n>>>\n>>>\n>>> On 09/06/2017 04:20 PM, Cornelia Huck wrote: \n>>>> On Wed, 6 Sep 2017 14:25:13 +0200\n>>>> Halil Pasic wrote:\n>>>> \n>>>>> We have basically two possibilities/options which ask for different\n>>>>> handling:\n>>>>> 1) EFAULT is due to a bug in the vfio-ccw implementation\n>>>>> (can be QEMU or kernel).\n>>>>> 2) EFAULT is due to buggy channel program.\n>>>>>\n>>>>> Option 2) is basically to be handled with a channel-program check and\n>>>>> setting primary secondary and alert status. For reference see PoP page\n>>>>> 15-59 (\"Designation of Storage Area\"). An exception may be an invalid\n>>>>> channel program address in the ORB. There the channel-program check ain't\n>>>>> explicitly stated (although) I would expect one. It may be implied by the\n>>>>> things on page 15-59 though.\n>>>>>\n>>>>> Option 1) is however very similar to other we have figured out that the\n>>>>> implementation is broken situations and should be handled consequently.\n>>>>> The current state of the discussion is with a unit exception.\n>>>>>\n>>>>> Does that make sense? \n>>>>\n>>>> I think the situation is slightly different here, though. For the orb\n>>>> flags, we reject something out of hand because we have not implemented\n>>>> it, and for that, unit exception sounds like a good fit. Processing\n>>>> errors, however, are more similar to errors in the hardware, and as\n>>>> such can probably be reported via something like equipment check.\n>>>> \n>>>\n>>> Noted. Let's see what Dong Jia has to say, before we continuing a\n>>> discussion on something (option 1) what may be irrelevant anyway.\n>>> \n>>>>>\n>>>>> Now, Dong Jia, I need your help to figure out do we have option 1 or\n>>>>> option 2 here? After quick look at the kernel code, it appears to me that\n>>>>> I've seen both option 1 and option 2 (I'm afraid) -- but my assessment\n>>>>> was really very superficial. \n>> There are three cases (all in the kernel) that generate a -EFAULT ret\n>> code:\n>> a. vfio_ccw_mdev_write: copy_from_user() fails.\n>> This is option 1.\n>>\n>> b. ccwchain_fetch_tic\n>> It's mostly likely that the vfio-ccw driver processed the ccw chains\n>> wrongly. (Actually I can not think of any other reason.)\n> \n> Me neither, I'd consider hitting this a bug in the implementation.\n\nNod.\n\n> \n>> This is option 1.\n>>\n>> c. ccwchain_fetch_idal\n>> When we find that an IDAW contents an invalid address\n>> This is option 2.\n>>\n>>>>>\n>>>>> I would expect option 2 to be handled differently (kernel provides the\n>>>>> SCSW) though.\n> \n> So we would do an equipment check for the first two (\"equipment\", i.e.\n> the software, is malfunctioning) and use a more appropriate way for the\n> malformed idaw?\n> \n\nYou have probably missed my previous email where I state something very\nsimilar (MID <2aa8cf98-c331-fe5a-0a7e-1a553c6c5054@linux.vnet.ibm.com>).\nThere I say: if we change the kernel code, yes, if we don't I prefer a\nprogram check.\n\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 3xnyy24rbdz9sRY\n\tfor ;\n\tThu, 7 Sep 2017 21:33:30 +1000 (AEST)","from localhost ([::1]:39874 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpv3o-0003BB-Jx\n\tfor incoming@patchwork.ozlabs.org; Thu, 07 Sep 2017 07:33:28 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:45657)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpv3G-00037h-Ua\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 07:32:59 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpv3C-0000Qa-5h\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 07:32:54 -0400","from mx0b-001b2d01.pphosted.com ([148.163.158.5]:57857\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 1dpv3B-0000QS-WD\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 07:32:50 -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\tv87BThb8051793\n\tfor ; Thu, 7 Sep 2017 07:32:48 -0400","from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2cu3ef63m8-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Thu, 07 Sep 2017 07:32:48 -0400","from localhost\n\tby e06smtp12.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:32:45 +0100","from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197)\n\tby e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tThu, 7 Sep 2017 12:32:42 +0100","from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com\n\t[9.149.105.232])\n\tby b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v87BWgV815925364; Thu, 7 Sep 2017 11:32:42 GMT","from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 7B5CD5204B;\n\tThu, 7 Sep 2017 11:27:58 +0100 (BST)","from oc3836556865.ibm.com (unknown [9.152.224.207])\n\tby d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id 1730A52043; \n\tThu, 7 Sep 2017 11:27:58 +0100 (BST)"],"To":"Cornelia Huck ,\n\tDong Jia Shi ","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-5-pasic@linux.vnet.ibm.com>\n\t<20170831115535.1e4201d3.cohuck@redhat.com>\n\t<7540741b-d230-e7c4-50d3-036f31997c8b@linux.vnet.ibm.com>\n\t<20170905182546.00457332.cohuck@redhat.com>\n\t\n\t<20170906043108.GY31680@bjsdjshi@linux.vnet.ibm.com>\n\t<8946b1ec-4d14-c953-deab-aaded7cd2c9d@linux.vnet.ibm.com>\n\t<20170906162019.45eeec4a.cohuck@redhat.com>\n\t\n\t<20170907085831.GF31680@bjsdjshi@linux.vnet.ibm.com>\n\t<20170907122400.5b2e3faa.cohuck@redhat.com>","From":"Halil Pasic ","Date":"Thu, 7 Sep 2017 13:32:41 +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":"<20170907122400.5b2e3faa.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":"17090711-0008-0000-0000-000004953A5B","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17090711-0009-0000-0000-00001E263C88","Message-Id":"<27b2addf-0d1c-81d7-1e82-1a8cdac70231@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-07_08:, , 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-1709070170","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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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":"Pierre Morel ,\n\tXiao Feng Ren , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1764669,"web_url":"http://patchwork.ozlabs.org/comment/1764669/","msgid":"<20170907134134.00f387e8.cohuck@redhat.com>","list_archive_url":null,"date":"2017-09-07T11:41:34","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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:32:41 +0200\nHalil Pasic wrote:\n\n> On 09/07/2017 12:24 PM, Cornelia Huck wrote:\n\n> > So we would do an equipment check for the first two (\"equipment\", i.e.\n> > the software, is malfunctioning) and use a more appropriate way for the\n> > malformed idaw?\n> > \n> \n> You have probably missed my previous email where I state something very\n> similar (MID <2aa8cf98-c331-fe5a-0a7e-1a553c6c5054@linux.vnet.ibm.com>).\n> There I say: if we change the kernel code, yes, if we don't I prefer a\n> program check.\n\nNot missed, they crossed in mid-air.\n\nBut I agree, the decision is Dong Jia's.","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-mx03.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx03.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 3xnz8249sCz9sRY\n\tfor ;\n\tThu, 7 Sep 2017 21:42:10 +1000 (AEST)","from localhost ([::1]:39897 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dpvCC-0005Tc-OA\n\tfor incoming@patchwork.ozlabs.org; Thu, 07 Sep 2017 07:42:08 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:48412)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dpvBn-0005T6-5j\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 07:41:47 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dpvBi-0003Hd-BW\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 07:41:43 -0400","from mx1.redhat.com ([209.132.183.28]:34712)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dpvBi-0003HG-5w\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 07:41:38 -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 1DD8C7E423;\n\tThu, 7 Sep 2017 11:41: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 3785419030;\n\tThu, 7 Sep 2017 11:41:36 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 1DD8C7E423","Date":"Thu, 7 Sep 2017 13:41:34 +0200","From":"Cornelia Huck ","To":"Halil Pasic ","Message-ID":"<20170907134134.00f387e8.cohuck@redhat.com>","In-Reply-To":"<27b2addf-0d1c-81d7-1e82-1a8cdac70231@linux.vnet.ibm.com>","References":"<20170830163609.50260-1-pasic@linux.vnet.ibm.com>\n\t<20170830163609.50260-5-pasic@linux.vnet.ibm.com>\n\t<20170831115535.1e4201d3.cohuck@redhat.com>\n\t<7540741b-d230-e7c4-50d3-036f31997c8b@linux.vnet.ibm.com>\n\t<20170905182546.00457332.cohuck@redhat.com>\n\t\n\t<20170906043108.GY31680@bjsdjshi@linux.vnet.ibm.com>\n\t<8946b1ec-4d14-c953-deab-aaded7cd2c9d@linux.vnet.ibm.com>\n\t<20170906162019.45eeec4a.cohuck@redhat.com>\n\t\n\t<20170907085831.GF31680@bjsdjshi@linux.vnet.ibm.com>\n\t<20170907122400.5b2e3faa.cohuck@redhat.com>\n\t<27b2addf-0d1c-81d7-1e82-1a8cdac70231@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.14","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.27]);\n\tThu, 07 Sep 2017 11:41: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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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\tXiao Feng Ren , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1765063,"web_url":"http://patchwork.ozlabs.org/comment/1765063/","msgid":"<20170908034100.GH31680@bjsdjshi@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-08T03:41:00","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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-07 13:41:34 +0200]:\n\n> On Thu, 7 Sep 2017 13:32:41 +0200\n> Halil Pasic wrote:\n> \n> > On 09/07/2017 12:24 PM, Cornelia Huck wrote:\n> \n> > > So we would do an equipment check for the first two (\"equipment\", i.e.\n> > > the software, is malfunctioning) and use a more appropriate way for the\n> > > malformed idaw?\n> > > \n> > \n> > You have probably missed my previous email where I state something very\n> > similar (MID <2aa8cf98-c331-fe5a-0a7e-1a553c6c5054@linux.vnet.ibm.com>).\n> > There I say: if we change the kernel code, yes, if we don't I prefer a\n> > program check.\n> \n> Not missed, they crossed in mid-air.\n> \n> But I agree, the decision is Dong Jia's.\n> \nLet' me summarize here, in case I misunderstand things. Now we have\ntwo ways to choose:\n\nA. Kernel: no change.\n Qemu : handle -EFAULT as option 2 by generating a program check.\n\nB. Kernel: return -EFAULT\n +\n update the IRB area in the I/O region for option 1 to present\n a unit check SCSW (with proper sense byte ECW), and for option\n 2 to present a program check.\n Qemu : handle -EFAULT according to the information that the IRB area\n provided.\n\nI think the difficult part is in the Qemu side. For either A or B, in\nQemu, we'd need to return a cc0 to indicate the channel program is\naccepted successfully by the device, and then update the virtual IRB and\ninject an I/O interrupt to notify the guest.\n\nThe question is, now we need to map -EFAULT to cc0? This is too odd...\nAnd we need to find a proper place to do the interrupt injection. I\nguess it could be in the sch_handle_start_func_passthrough().\n\nIf we do not like such modification in the Qemu side, then A is not the\nway to go.\n\nAnd for B, we need to update the IRB area of the I/O region in the three\ncases listed in the former mail, and:\n1. We need to set the ret_code as 0 for them, so that Qemu could map it\n to cc0.\n2. We need to signal Qemu to fetch the IRB we generated with the checks.\nAll of these are doable I think.\n\nAny comment for the above thoughts?","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 3xpNR74Xjmz9sPk\n\tfor ;\n\tFri, 8 Sep 2017 13:41:39 +1000 (AEST)","from localhost ([::1]:43159 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dqAAj-0005uU-Ny\n\tfor incoming@patchwork.ozlabs.org; Thu, 07 Sep 2017 23:41:37 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:36812)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dqAAK-0005uA-41\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 23:41:16 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dqAAF-0007q2-6p\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 23:41:12 -0400","from mx0b-001b2d01.pphosted.com ([148.163.158.5]:44339\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 1dqAAE-0007pM-Tb\n\tfor qemu-devel@nongnu.org; Thu, 07 Sep 2017 23:41:07 -0400","from pps.filterd (m0098416.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv883dZnL126657\n\tfor ; Thu, 7 Sep 2017 23:41:05 -0400","from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2cuc9mukht-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Thu, 07 Sep 2017 23:41:05 -0400","from localhost\n\tby e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tThu, 7 Sep 2017 21:41:04 -0600","from b03cxnp08025.gho.boulder.ibm.com (9.17.130.17)\n\tby e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tThu, 7 Sep 2017 21:41:02 -0600","from b03ledav006.gho.boulder.ibm.com\n\t(b03ledav006.gho.boulder.ibm.com [9.17.130.237])\n\tby b03cxnp08025.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v883f2W264225458; Thu, 7 Sep 2017 20:41:02 -0700","from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 28D52C60D7;\n\tThu, 7 Sep 2017 21:41:02 -0600 (MDT)","from localhost (unknown [9.115.112.23])\n\tby b03ledav006.gho.boulder.ibm.com (Postfix) with ESMTP id 719F6C603E;\n\tThu, 7 Sep 2017 21:41:01 -0600 (MDT)"],"Date":"Fri, 8 Sep 2017 11:41:00 +0800","From":"Dong Jia Shi ","To":"Cornelia Huck ","Mail-Followup-To":"Cornelia Huck ,\n\tHalil Pasic ,\n\tDong Jia Shi ,\n\tPierre Morel ,\n\tXiao Feng Ren , qemu-devel@nongnu.org","References":"<20170905182546.00457332.cohuck@redhat.com>\n\t\n\t<20170906043108.GY31680@bjsdjshi@linux.vnet.ibm.com>\n\t<8946b1ec-4d14-c953-deab-aaded7cd2c9d@linux.vnet.ibm.com>\n\t<20170906162019.45eeec4a.cohuck@redhat.com>\n\t\n\t<20170907085831.GF31680@bjsdjshi@linux.vnet.ibm.com>\n\t<20170907122400.5b2e3faa.cohuck@redhat.com>\n\t<27b2addf-0d1c-81d7-1e82-1a8cdac70231@linux.vnet.ibm.com>\n\t<20170907134134.00f387e8.cohuck@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170907134134.00f387e8.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":"17090803-0004-0000-0000-000012E47101","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007686; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000226; SDB=6.00913851; UDB=6.00458699;\n\tIPR=6.00694109; \n\tBA=6.00005576; 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.00017061;\n\tXFM=3.00000015; UTC=2017-09-08 03:41:03","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17090803-0005-0000-0000-000084014054","Message-Id":"<20170908034100.GH31680@bjsdjshi@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-08_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-1709080056","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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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":"qemu-devel@nongnu.org, Halil Pasic ,\n\tPierre Morel ,\n\tDong Jia Shi ,\n\tXiao Feng Ren ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1765193,"web_url":"http://patchwork.ozlabs.org/comment/1765193/","msgid":"<381cb778-5679-634c-9d3d-7276f877da3a@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-08T09:21:57","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","submitter":{"id":68297,"url":"http://patchwork.ozlabs.org/api/people/68297/","name":"Halil Pasic","email":"pasic@linux.vnet.ibm.com"},"content":"On 09/08/2017 05:41 AM, Dong Jia Shi wrote:\n> Let' me summarize here, in case I misunderstand things. Now we have\n> two ways to choose:\n> \n> A. Kernel: no change.\n> Qemu : handle -EFAULT as option 2 by generating a program check.\n> \n> B. Kernel: return -EFAULT\n> +\n> update the IRB area in the I/O region for option 1 to present\n> a unit check SCSW (with proper sense byte ECW), and for option\n> 2 to present a program check.\n> Qemu : handle -EFAULT according to the information that the IRB area\n> provided.\n\nThis is not what I was trying to say. You got my message regarding A, but\nB was supposed to be understood like this.\n\nKeep the current handling for option 1, that is return -EFAULT. For option\n2 do what the spec says, execute the program until the bad address and then\ngenerate a program-check (SCSW) once the bad stuff has it's turn. Thus\nthe only change in QEMU would be handling -EFAULT with an unit check (because\nnow it's just option 1).\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 3xpX6C6vfJz9rxm\n\tfor ;\n\tFri, 8 Sep 2017 19:27:31 +1000 (AEST)","from localhost ([::1]:44084 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dqFZS-0005p5-31\n\tfor incoming@patchwork.ozlabs.org; Fri, 08 Sep 2017 05:27:30 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:54868)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dqFUH-0001fx-Ny\n\tfor qemu-devel@nongnu.org; Fri, 08 Sep 2017 05:22:14 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dqFUD-0005Qo-7n\n\tfor qemu-devel@nongnu.org; Fri, 08 Sep 2017 05:22:09 -0400","from mx0b-001b2d01.pphosted.com ([148.163.158.5]:41534\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 1dqFUD-0005Q5-1E\n\tfor qemu-devel@nongnu.org; Fri, 08 Sep 2017 05:22:05 -0400","from pps.filterd (m0098419.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv889J7Ga100063\n\tfor ; Fri, 8 Sep 2017 05:22:04 -0400","from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2cur2s98w2-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Fri, 08 Sep 2017 05:22:02 -0400","from localhost\n\tby e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tFri, 8 Sep 2017 10:22:01 +0100","from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195)\n\tby e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tFri, 8 Sep 2017 10:21:58 +0100","from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com\n\t[9.149.105.60])\n\tby b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v889LwmF28704920; Fri, 8 Sep 2017 09:21:58 GMT","from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 36B4A42042;\n\tFri, 8 Sep 2017 10:18:26 +0100 (BST)","from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 95F0F4203F;\n\tFri, 8 Sep 2017 10:18:25 +0100 (BST)","from oc3836556865.ibm.com (unknown [9.152.224.207])\n\tby d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP;\n\tFri, 8 Sep 2017 10:18:25 +0100 (BST)"],"To":"Cornelia Huck ,\n\tDong Jia Shi ,\n\tPierre Morel ,\n\tXiao Feng Ren , qemu-devel@nongnu.org","References":"<20170905182546.00457332.cohuck@redhat.com>\n\t\n\t<20170906043108.GY31680@bjsdjshi@linux.vnet.ibm.com>\n\t<8946b1ec-4d14-c953-deab-aaded7cd2c9d@linux.vnet.ibm.com>\n\t<20170906162019.45eeec4a.cohuck@redhat.com>\n\t\n\t<20170907085831.GF31680@bjsdjshi@linux.vnet.ibm.com>\n\t<20170907122400.5b2e3faa.cohuck@redhat.com>\n\t<27b2addf-0d1c-81d7-1e82-1a8cdac70231@linux.vnet.ibm.com>\n\t<20170907134134.00f387e8.cohuck@redhat.com>\n\t<20170908034100.GH31680@bjsdjshi@linux.vnet.ibm.com>","From":"Halil Pasic ","Date":"Fri, 8 Sep 2017 11:21:57 +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":"<20170908034100.GH31680@bjsdjshi@linux.vnet.ibm.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-TM-AS-GCONF":"00","x-cbid":"17090809-0008-0000-0000-000004957E79","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17090809-0009-0000-0000-00001E268435","Message-Id":"<381cb778-5679-634c-9d3d-7276f877da3a@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-08_06:, , 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-1709080143","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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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":1765221,"web_url":"http://patchwork.ozlabs.org/comment/1765221/","msgid":"<20170908115950.56996cc6.cohuck@redhat.com>","list_archive_url":null,"date":"2017-09-08T09:59:50","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","submitter":{"id":71914,"url":"http://patchwork.ozlabs.org/api/people/71914/","name":"Cornelia Huck","email":"cohuck@redhat.com"},"content":"On Fri, 8 Sep 2017 11:21:57 +0200\nHalil Pasic wrote:\n\n> On 09/08/2017 05:41 AM, Dong Jia Shi wrote:\n> > Let' me summarize here, in case I misunderstand things. Now we have\n> > two ways to choose:\n> > \n> > A. Kernel: no change.\n> > Qemu : handle -EFAULT as option 2 by generating a program check.\n> > \n> > B. Kernel: return -EFAULT\n> > +\n> > update the IRB area in the I/O region for option 1 to present\n> > a unit check SCSW (with proper sense byte ECW), and for option\n> > 2 to present a program check.\n> > Qemu : handle -EFAULT according to the information that the IRB area\n> > provided. \n> \n> This is not what I was trying to say. You got my message regarding A, but\n> B was supposed to be understood like this.\n> \n> Keep the current handling for option 1, that is return -EFAULT. For option\n> 2 do what the spec says, execute the program until the bad address and then\n> generate a program-check (SCSW) once the bad stuff has it's turn. Thus\n> the only change in QEMU would be handling -EFAULT with an unit check (because\n> now it's just option 1).\n\nThat makes sense to me.","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 3xpYCB48Pwz9s3T\n\tfor ;\n\tFri, 8 Sep 2017 20:16:54 +1000 (AEST)","from localhost ([::1]:44336 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dqGLE-0001fK-Dh\n\tfor incoming@patchwork.ozlabs.org; Fri, 08 Sep 2017 06:16:52 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:43746)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dqG4t-0003XE-LV\n\tfor qemu-devel@nongnu.org; Fri, 08 Sep 2017 06:00:04 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dqG4p-0007up-6Y\n\tfor qemu-devel@nongnu.org; Fri, 08 Sep 2017 05:59:59 -0400","from mx1.redhat.com ([209.132.183.28]:45492)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dqG4o-0007uP-W5\n\tfor qemu-devel@nongnu.org; Fri, 08 Sep 2017 05:59:55 -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 DC9A581DFC;\n\tFri, 8 Sep 2017 09:59:53 +0000 (UTC)","from gondolin (dhcp-192-215.str.redhat.com [10.33.192.215])\n\tby smtp.corp.redhat.com (Postfix) with ESMTP id D25735D97C;\n\tFri, 8 Sep 2017 09:59:52 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com DC9A581DFC","Date":"Fri, 8 Sep 2017 11:59:50 +0200","From":"Cornelia Huck ","To":"Halil Pasic ","Message-ID":"<20170908115950.56996cc6.cohuck@redhat.com>","In-Reply-To":"<381cb778-5679-634c-9d3d-7276f877da3a@linux.vnet.ibm.com>","References":"<20170905182546.00457332.cohuck@redhat.com>\n\t\n\t<20170906043108.GY31680@bjsdjshi@linux.vnet.ibm.com>\n\t<8946b1ec-4d14-c953-deab-aaded7cd2c9d@linux.vnet.ibm.com>\n\t<20170906162019.45eeec4a.cohuck@redhat.com>\n\t\n\t<20170907085831.GF31680@bjsdjshi@linux.vnet.ibm.com>\n\t<20170907122400.5b2e3faa.cohuck@redhat.com>\n\t<27b2addf-0d1c-81d7-1e82-1a8cdac70231@linux.vnet.ibm.com>\n\t<20170907134134.00f387e8.cohuck@redhat.com>\n\t<20170908034100.GH31680@bjsdjshi@linux.vnet.ibm.com>\n\t<381cb778-5679-634c-9d3d-7276f877da3a@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.14","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.25]);\n\tFri, 08 Sep 2017 09:59:54 +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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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\tXiao Feng Ren , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1765225,"web_url":"http://patchwork.ozlabs.org/comment/1765225/","msgid":"<20170908120238.13a13ce0.cohuck@redhat.com>","list_archive_url":null,"date":"2017-09-08T10:02:38","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","submitter":{"id":71914,"url":"http://patchwork.ozlabs.org/api/people/71914/","name":"Cornelia Huck","email":"cohuck@redhat.com"},"content":"On Fri, 8 Sep 2017 11:41:00 +0800\nDong Jia Shi wrote:\n\n> I think the difficult part is in the Qemu side. For either A or B, in\n> Qemu, we'd need to return a cc0 to indicate the channel program is\n> accepted successfully by the device, and then update the virtual IRB and\n> inject an I/O interrupt to notify the guest.\n> \n> The question is, now we need to map -EFAULT to cc0? This is too odd...\n\nIt's not odd at all, if you consider these as two stages:\n\n- Initial acceptance of the command, set cc 0 to indicate you got it.\n- Execution of the start function. This can then fail, of course.\n\n> And we need to find a proper place to do the interrupt injection. I\n> guess it could be in the sch_handle_start_func_passthrough().\n\nProbably, yes.\n\n> \n> If we do not like such modification in the Qemu side, then A is not the\n> way to go.\n> \n> And for B, we need to update the IRB area of the I/O region in the three\n> cases listed in the former mail, and:\n> 1. We need to set the ret_code as 0 for them, so that Qemu could map it\n> to cc0.\n> 2. We need to signal Qemu to fetch the IRB we generated with the checks.\n> All of these are doable I think.\n> \n> Any comment for the above thoughts?\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-mx08.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx08.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 3xpYMW5rBFz9s3T\n\tfor ;\n\tFri, 8 Sep 2017 20:24:07 +1000 (AEST)","from localhost ([::1]:44364 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dqGSD-00083d-Bu\n\tfor incoming@patchwork.ozlabs.org; Fri, 08 Sep 2017 06:24:05 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:45199)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dqG7b-00067L-9m\n\tfor qemu-devel@nongnu.org; Fri, 08 Sep 2017 06:02:51 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dqG7W-0001pT-Kv\n\tfor qemu-devel@nongnu.org; Fri, 08 Sep 2017 06:02:47 -0400","from mx1.redhat.com ([209.132.183.28]:58334)\n\tby eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from ) id 1dqG7W-0001o5-FQ\n\tfor qemu-devel@nongnu.org; Fri, 08 Sep 2017 06:02:42 -0400","from smtp.corp.redhat.com\n\t(int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15])\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 6C5A6C0587EB;\n\tFri, 8 Sep 2017 10:02: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 616936AD18;\n\tFri, 8 Sep 2017 10:02:40 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 6C5A6C0587EB","Date":"Fri, 8 Sep 2017 12:02:38 +0200","From":"Cornelia Huck ","To":"Dong Jia Shi ","Message-ID":"<20170908120238.13a13ce0.cohuck@redhat.com>","In-Reply-To":"<20170908034100.GH31680@bjsdjshi@linux.vnet.ibm.com>","References":"<20170905182546.00457332.cohuck@redhat.com>\n\t\n\t<20170906043108.GY31680@bjsdjshi@linux.vnet.ibm.com>\n\t<8946b1ec-4d14-c953-deab-aaded7cd2c9d@linux.vnet.ibm.com>\n\t<20170906162019.45eeec4a.cohuck@redhat.com>\n\t\n\t<20170907085831.GF31680@bjsdjshi@linux.vnet.ibm.com>\n\t<20170907122400.5b2e3faa.cohuck@redhat.com>\n\t<27b2addf-0d1c-81d7-1e82-1a8cdac70231@linux.vnet.ibm.com>\n\t<20170907134134.00f387e8.cohuck@redhat.com>\n\t<20170908034100.GH31680@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.15","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.32]);\n\tFri, 08 Sep 2017 10:02: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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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\tXiao Feng Ren , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1774456,"web_url":"http://patchwork.ozlabs.org/comment/1774456/","msgid":"<20170925071404.GQ11080@bjsdjshi@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-25T07:14:04","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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-08 12:02:38 +0200]:\n\n> On Fri, 8 Sep 2017 11:41:00 +0800\n> Dong Jia Shi wrote:\n> \n> > I think the difficult part is in the Qemu side. For either A or B, in\n> > Qemu, we'd need to return a cc0 to indicate the channel program is\n> > accepted successfully by the device, and then update the virtual IRB and\n> > inject an I/O interrupt to notify the guest.\n> > \n> > The question is, now we need to map -EFAULT to cc0? This is too odd...\n> \n> It's not odd at all, if you consider these as two stages:\n> \n> - Initial acceptance of the command, set cc 0 to indicate you got it.\n> - Execution of the start function. This can then fail, of course.\nOk. I got the idea!\n\n> \n> > And we need to find a proper place to do the interrupt injection. I\n> > guess it could be in the sch_handle_start_func_passthrough().\n> \n> Probably, yes.\n> \n> > \n> > If we do not like such modification in the Qemu side, then A is not the\n> > way to go.\n> > \n> > And for B, we need to update the IRB area of the I/O region in the three\n> > cases listed in the former mail, and:\n> > 1. We need to set the ret_code as 0 for them, so that Qemu could map it\n> > to cc0.\n> > 2. We need to signal Qemu to fetch the IRB we generated with the checks.\n> > All of these are doable I think.\n> > \n> > Any comment for the above thoughts?\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 3y0wMY3YWfz9tXG\n\tfor ;\n\tMon, 25 Sep 2017 17:14:59 +1000 (AEST)","from localhost ([::1]:40977 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dwNbT-00062q-00\n\tfor incoming@patchwork.ozlabs.org; Mon, 25 Sep 2017 03:14:55 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:59727)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dwNaq-00062Z-W1\n\tfor qemu-devel@nongnu.org; Mon, 25 Sep 2017 03:14:17 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dwNan-00057M-Ox\n\tfor qemu-devel@nongnu.org; Mon, 25 Sep 2017 03:14:16 -0400","from mx0b-001b2d01.pphosted.com ([148.163.158.5]:58524\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 1dwNan-00056t-Ja\n\tfor qemu-devel@nongnu.org; Mon, 25 Sep 2017 03:14:13 -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\tv8P79LmH114395\n\tfor ; Mon, 25 Sep 2017 03:14:09 -0400","from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2d6w3v8ebw-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Mon, 25 Sep 2017 03:14:09 -0400","from localhost\n\tby e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tMon, 25 Sep 2017 01:14:08 -0600","from b03cxnp08028.gho.boulder.ibm.com (9.17.130.20)\n\tby e35.co.us.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tMon, 25 Sep 2017 01:14:06 -0600","from b03ledav006.gho.boulder.ibm.com\n\t(b03ledav006.gho.boulder.ibm.com [9.17.130.237])\n\tby b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v8P7E6lq31916192; Mon, 25 Sep 2017 00:14:06 -0700","from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 62B1AC603E;\n\tMon, 25 Sep 2017 01:14:06 -0600 (MDT)","from localhost (unknown [9.115.112.23])\n\tby b03ledav006.gho.boulder.ibm.com (Postfix) with ESMTP id AEE7AC6037;\n\tMon, 25 Sep 2017 01:14:05 -0600 (MDT)"],"Date":"Mon, 25 Sep 2017 15:14:04 +0800","From":"Dong Jia Shi ","To":"Cornelia Huck ","Mail-Followup-To":"Cornelia Huck ,\n\tDong Jia Shi ,\n\tHalil Pasic ,\n\tPierre Morel ,\n\tXiao Feng Ren , qemu-devel@nongnu.org","References":"<20170906043108.GY31680@bjsdjshi@linux.vnet.ibm.com>\n\t<8946b1ec-4d14-c953-deab-aaded7cd2c9d@linux.vnet.ibm.com>\n\t<20170906162019.45eeec4a.cohuck@redhat.com>\n\t\n\t<20170907085831.GF31680@bjsdjshi@linux.vnet.ibm.com>\n\t<20170907122400.5b2e3faa.cohuck@redhat.com>\n\t<27b2addf-0d1c-81d7-1e82-1a8cdac70231@linux.vnet.ibm.com>\n\t<20170907134134.00f387e8.cohuck@redhat.com>\n\t<20170908034100.GH31680@bjsdjshi@linux.vnet.ibm.com>\n\t<20170908120238.13a13ce0.cohuck@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170908120238.13a13ce0.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":"17092507-0012-0000-0000-0000150DD0DC","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007788; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000231; SDB=6.00922031; UDB=6.00463393;\n\tIPR=6.00702173; \n\tBA=6.00005602; 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.00017262;\n\tXFM=3.00000015; UTC=2017-09-25 07:14:07","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17092507-0013-0000-0000-00004F9F44FD","Message-Id":"<20170925071404.GQ11080@bjsdjshi@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-25_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-1709250111","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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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":"qemu-devel@nongnu.org, Dong Jia Shi ,\n\tPierre Morel ,\n\tHalil Pasic ,\n\tXiao Feng Ren ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1774477,"web_url":"http://patchwork.ozlabs.org/comment/1774477/","msgid":"<20170925073159.GR11080@bjsdjshi@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-25T07:31:59","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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-08 11:59:50 +0200]:\n\n> On Fri, 8 Sep 2017 11:21:57 +0200\n> Halil Pasic wrote:\n> \n> > On 09/08/2017 05:41 AM, Dong Jia Shi wrote:\n> > > Let' me summarize here, in case I misunderstand things. Now we have\n> > > two ways to choose:\n> > > \n> > > A. Kernel: no change.\n> > > Qemu : handle -EFAULT as option 2 by generating a program check.\n> > > \n> > > B. Kernel: return -EFAULT\n> > > +\n> > > update the IRB area in the I/O region for option 1 to present\n> > > a unit check SCSW (with proper sense byte ECW), and for option\n> > > 2 to present a program check.\n> > > Qemu : handle -EFAULT according to the information that the IRB area\n> > > provided. \n> > \n> > This is not what I was trying to say. You got my message regarding A, but\n> > B was supposed to be understood like this.\n> > \n> > Keep the current handling for option 1, that is return -EFAULT. For option\n> > 2 do what the spec says, execute the program until the bad address and then\n> > generate a program-check (SCSW) once the bad stuff has it's turn. Thus\n> > the only change in QEMU would be handling -EFAULT with an unit check (because\n> > now it's just option 1).\nLet me adding some context information here by copying some words from the\nprevious mail in this thread:\nThe only option 2 case in the kernel is ccwchain_fetch_idal() finding a\nbad idaw_iova.\n\nWhat you propose to do for this case is (correct me if I get it wrong):\nIn ccwchain_fetch_idal(), we do not return -EFAULT, instead we return 0,\nand issuing the incompletely translated channel program with the bad\naddress to the physical device. And QEMU will eventually get the SCSW\nwith the program-check from the physical device I/O result, and inject\nit to guest for further handling.\n\nIs this understanding right? If so, I'm fine with that, and I can\nprovide the fix in the kernel.\n\n> \n> That makes sense to me.\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 3y0wm96Bpvz9tXM\n\tfor ;\n\tMon, 25 Sep 2017 17:32:57 +1000 (AEST)","from localhost ([::1]:41094 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dwNst-0005QE-Sy\n\tfor incoming@patchwork.ozlabs.org; Mon, 25 Sep 2017 03:32:55 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:36157)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dwNsF-0005CH-Ph\n\tfor qemu-devel@nongnu.org; Mon, 25 Sep 2017 03:32:16 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dwNsA-0001Kd-OM\n\tfor qemu-devel@nongnu.org; Mon, 25 Sep 2017 03:32:15 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:49868)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dwNsA-0001KA-Ft\n\tfor qemu-devel@nongnu.org; Mon, 25 Sep 2017 03:32:10 -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\tv8P7T90E136460\n\tfor ; Mon, 25 Sep 2017 03:32:06 -0400","from e12.ny.us.ibm.com (e12.ny.us.ibm.com [129.33.205.202])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2d6p5xttxs-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Mon, 25 Sep 2017 03:32:06 -0400","from localhost\n\tby e12.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tMon, 25 Sep 2017 03:32:05 -0400","from b01cxnp23032.gho.pok.ibm.com (9.57.198.27)\n\tby e12.ny.us.ibm.com (146.89.104.199) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tMon, 25 Sep 2017 03:32:02 -0400","from b01ledav001.gho.pok.ibm.com (b01ledav001.gho.pok.ibm.com\n\t[9.57.199.106])\n\tby b01cxnp23032.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP\n\tid v8P7W1lm26542196; Mon, 25 Sep 2017 07:32:01 GMT","from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id ED8052804A;\n\tMon, 25 Sep 2017 03:31:54 -0400 (EDT)","from localhost (unknown [9.115.112.23])\n\tby b01ledav001.gho.pok.ibm.com (Postfix) with ESMTP id 25C112803E;\n\tMon, 25 Sep 2017 03:31:53 -0400 (EDT)"],"Date":"Mon, 25 Sep 2017 15:31:59 +0800","From":"Dong Jia Shi ","To":"Cornelia Huck ","Mail-Followup-To":"Cornelia Huck ,\n\tHalil Pasic ,\n\tDong Jia Shi ,\n\tPierre Morel ,\n\tXiao Feng Ren , qemu-devel@nongnu.org","References":"<8946b1ec-4d14-c953-deab-aaded7cd2c9d@linux.vnet.ibm.com>\n\t<20170906162019.45eeec4a.cohuck@redhat.com>\n\t\n\t<20170907085831.GF31680@bjsdjshi@linux.vnet.ibm.com>\n\t<20170907122400.5b2e3faa.cohuck@redhat.com>\n\t<27b2addf-0d1c-81d7-1e82-1a8cdac70231@linux.vnet.ibm.com>\n\t<20170907134134.00f387e8.cohuck@redhat.com>\n\t<20170908034100.GH31680@bjsdjshi@linux.vnet.ibm.com>\n\t<381cb778-5679-634c-9d3d-7276f877da3a@linux.vnet.ibm.com>\n\t<20170908115950.56996cc6.cohuck@redhat.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170908115950.56996cc6.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":"17092507-0048-0000-0000-000001EA7330","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007788; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000231; SDB=6.00922037; UDB=6.00463397;\n\tIPR=6.00702179; \n\tBA=6.00005602; 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.00017262;\n\tXFM=3.00000015; UTC=2017-09-25 07:32:03","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17092507-0049-0000-0000-000042AB4B02","Message-Id":"<20170925073159.GR11080@bjsdjshi@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-25_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-1709250116","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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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":"qemu-devel@nongnu.org, Halil Pasic ,\n\tPierre Morel ,\n\tDong Jia Shi ,\n\tXiao Feng Ren ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}},{"id":1774649,"web_url":"http://patchwork.ozlabs.org/comment/1774649/","msgid":"","list_archive_url":null,"date":"2017-09-25T10:57:31","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","submitter":{"id":68297,"url":"http://patchwork.ozlabs.org/api/people/68297/","name":"Halil Pasic","email":"pasic@linux.vnet.ibm.com"},"content":"On 09/25/2017 09:31 AM, Dong Jia Shi wrote:\n> * Cornelia Huck [2017-09-08 11:59:50 +0200]:\n> \n>> On Fri, 8 Sep 2017 11:21:57 +0200\n>> Halil Pasic wrote:\n>>\n>>> On 09/08/2017 05:41 AM, Dong Jia Shi wrote:\n>>>> Let' me summarize here, in case I misunderstand things. Now we have\n>>>> two ways to choose:\n>>>>\n>>>> A. Kernel: no change.\n>>>> Qemu : handle -EFAULT as option 2 by generating a program check.\n>>>>\n>>>> B. Kernel: return -EFAULT\n>>>> +\n>>>> update the IRB area in the I/O region for option 1 to present\n>>>> a unit check SCSW (with proper sense byte ECW), and for option\n>>>> 2 to present a program check.\n>>>> Qemu : handle -EFAULT according to the information that the IRB area\n>>>> provided. \n>>>\n>>> This is not what I was trying to say. You got my message regarding A, but\n>>> B was supposed to be understood like this.\n>>>\n>>> Keep the current handling for option 1, that is return -EFAULT. For option\n>>> 2 do what the spec says, execute the program until the bad address and then\n>>> generate a program-check (SCSW) once the bad stuff has it's turn. Thus\n>>> the only change in QEMU would be handling -EFAULT with an unit check (because\n>>> now it's just option 1).\n> Let me adding some context information here by copying some words from the\n> previous mail in this thread:\n> The only option 2 case in the kernel is ccwchain_fetch_idal() finding a\n> bad idaw_iova.\n> \n> What you propose to do for this case is (correct me if I get it wrong):\n> In ccwchain_fetch_idal(), we do not return -EFAULT, instead we return 0,\n> and issuing the incompletely translated channel program with the bad\n> address to the physical device. And QEMU will eventually get the SCSW\n> with the program-check from the physical device I/O result, and inject\n> it to guest for further handling.\n> \n\nI guess that would be the cleanest. I would also be fine with not making\nthe physical device program-check (issuing a shortened channel program,\nand doing the program check in software) but that's probably more\ncomplicated to implement.\n\n> Is this understanding right? If so, I'm fine with that, and I can\n> provide the fix in the kernel.\n> \n\nThat would be nice.\n\n>>\n>> That makes sense to 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 3y11K36jqcz9tXC\n\tfor ;\n\tMon, 25 Sep 2017 20:58:13 +1000 (AEST)","from localhost ([::1]:41718 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dwR5V-00084L-Rh\n\tfor incoming@patchwork.ozlabs.org; Mon, 25 Sep 2017 06:58:09 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:52905)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dwR56-00082j-Ub\n\tfor qemu-devel@nongnu.org; Mon, 25 Sep 2017 06:57:45 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dwR53-0002Rp-Sw\n\tfor qemu-devel@nongnu.org; Mon, 25 Sep 2017 06:57:45 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:37646)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dwR53-0002RJ-J1\n\tfor qemu-devel@nongnu.org; Mon, 25 Sep 2017 06:57:41 -0400","from pps.filterd (m0098410.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv8PAraVx081641\n\tfor ; Mon, 25 Sep 2017 06:57:37 -0400","from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2d6yp4axy3-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Mon, 25 Sep 2017 06:57:35 -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\tMon, 25 Sep 2017 11:57:33 +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\tMon, 25 Sep 2017 11:57:31 +0100","from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com\n\t[9.149.105.62])\n\tby b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v8PAvVnd20906090\n\tfor ; Mon, 25 Sep 2017 10:57:31 GMT","from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 33C47AE051\n\tfor ; Mon, 25 Sep 2017 11:52:16 +0100 (BST)","from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 07C5CAE045\n\tfor ; Mon, 25 Sep 2017 11:52:16 +0100 (BST)","from oc3836556865.ibm.com (unknown [9.152.224.207])\n\tby d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP\n\tfor ; Mon, 25 Sep 2017 11:52:15 +0100 (BST)"],"To":"qemu-devel@nongnu.org","References":"<8946b1ec-4d14-c953-deab-aaded7cd2c9d@linux.vnet.ibm.com>\n\t<20170906162019.45eeec4a.cohuck@redhat.com>\n\t\n\t<20170907085831.GF31680@bjsdjshi@linux.vnet.ibm.com>\n\t<20170907122400.5b2e3faa.cohuck@redhat.com>\n\t<27b2addf-0d1c-81d7-1e82-1a8cdac70231@linux.vnet.ibm.com>\n\t<20170907134134.00f387e8.cohuck@redhat.com>\n\t<20170908034100.GH31680@bjsdjshi@linux.vnet.ibm.com>\n\t<381cb778-5679-634c-9d3d-7276f877da3a@linux.vnet.ibm.com>\n\t<20170908115950.56996cc6.cohuck@redhat.com>\n\t<20170925073159.GR11080@bjsdjshi@linux.vnet.ibm.com>","From":"Halil Pasic ","Date":"Mon, 25 Sep 2017 12:57:31 +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":"<20170925073159.GR11080@bjsdjshi@linux.vnet.ibm.com>","Content-Type":"text/plain; charset=utf-8","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","X-TM-AS-GCONF":"00","x-cbid":"17092510-0012-0000-0000-0000057BDA50","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17092510-0013-0000-0000-000018F522DD","Message-Id":"","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-25_04:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=1\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-1709250170","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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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":1776108,"web_url":"http://patchwork.ozlabs.org/comment/1776108/","msgid":"<20170927075517.GB5870@bjsdjshi@linux.vnet.ibm.com>","list_archive_url":null,"date":"2017-09-27T07:55:17","subject":"Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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-25 12:57:31 +0200]:\n\n[restored Cc:]\n\n> \n> \n> On 09/25/2017 09:31 AM, Dong Jia Shi wrote:\n> > * Cornelia Huck [2017-09-08 11:59:50 +0200]:\n> > \n> >> On Fri, 8 Sep 2017 11:21:57 +0200\n> >> Halil Pasic wrote:\n> >>\n> >>> On 09/08/2017 05:41 AM, Dong Jia Shi wrote:\n> >>>> Let' me summarize here, in case I misunderstand things. Now we have\n> >>>> two ways to choose:\n> >>>>\n> >>>> A. Kernel: no change.\n> >>>> Qemu : handle -EFAULT as option 2 by generating a program check.\n> >>>>\n> >>>> B. Kernel: return -EFAULT\n> >>>> +\n> >>>> update the IRB area in the I/O region for option 1 to present\n> >>>> a unit check SCSW (with proper sense byte ECW), and for option\n> >>>> 2 to present a program check.\n> >>>> Qemu : handle -EFAULT according to the information that the IRB area\n> >>>> provided. \n> >>>\n> >>> This is not what I was trying to say. You got my message regarding A, but\n> >>> B was supposed to be understood like this.\n> >>>\n> >>> Keep the current handling for option 1, that is return -EFAULT. For option\n> >>> 2 do what the spec says, execute the program until the bad address and then\n> >>> generate a program-check (SCSW) once the bad stuff has it's turn. Thus\n> >>> the only change in QEMU would be handling -EFAULT with an unit check (because\n> >>> now it's just option 1).\n> > Let me adding some context information here by copying some words from the\n> > previous mail in this thread:\n> > The only option 2 case in the kernel is ccwchain_fetch_idal() finding a\n> > bad idaw_iova.\n> > \n> > What you propose to do for this case is (correct me if I get it wrong):\n> > In ccwchain_fetch_idal(), we do not return -EFAULT, instead we return 0,\n> > and issuing the incompletely translated channel program with the bad\n> > address to the physical device. And QEMU will eventually get the SCSW\n> > with the program-check from the physical device I/O result, and inject\n> > it to guest for further handling.\n> > \n> \n> I guess that would be the cleanest. I would also be fine with not making\n> the physical device program-check (issuing a shortened channel program,\n> and doing the program check in software) but that's probably more\n> complicated to implement.\nThat's far more complicated. I will try the simple approach.\n\n> > Is this understanding right? If so, I'm fine with that, and I can\n> > provide the fix in the kernel.\n> > \n> \n> That would be nice.\nOk.","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 3y29PX0pZPz9sRq\n\tfor ;\n\tWed, 27 Sep 2017 18:06:08 +1000 (AEST)","from localhost ([::1]:53156 helo=lists.gnu.org)\n\tby lists.gnu.org with esmtp (Exim 4.71) (envelope-from\n\t)\n\tid 1dx7M5-0002td-VI\n\tfor incoming@patchwork.ozlabs.org; Wed, 27 Sep 2017 04:06:05 -0400","from eggs.gnu.org ([2001:4830:134:3::10]:32908)\n\tby lists.gnu.org with esmtp (Exim 4.71)\n\t(envelope-from ) id 1dx7Bs-0003mI-Sl\n\tfor qemu-devel@nongnu.org; Wed, 27 Sep 2017 03:55:33 -0400","from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)\n\t(envelope-from ) id 1dx7Bo-0000vS-3i\n\tfor qemu-devel@nongnu.org; Wed, 27 Sep 2017 03:55:32 -0400","from mx0a-001b2d01.pphosted.com ([148.163.156.1]:40396)\n\tby eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)\n\t(Exim 4.71) (envelope-from )\n\tid 1dx7Bn-0000s0-Lt\n\tfor qemu-devel@nongnu.org; Wed, 27 Sep 2017 03:55:27 -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\tv8R7tEtj017098\n\tfor ; Wed, 27 Sep 2017 03:55:22 -0400","from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2d808ad5x7-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Wed, 27 Sep 2017 03:55:22 -0400","from localhost\n\tby e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tWed, 27 Sep 2017 01:55:21 -0600","from b03cxnp08026.gho.boulder.ibm.com (9.17.130.18)\n\tby e36.co.us.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tWed, 27 Sep 2017 01:55:20 -0600","from b03ledav002.gho.boulder.ibm.com\n\t(b03ledav002.gho.boulder.ibm.com [9.17.130.233])\n\tby b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v8R7tB5A64225326; Wed, 27 Sep 2017 00:55:19 -0700","from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id A8C9C13603A;\n\tWed, 27 Sep 2017 01:55:19 -0600 (MDT)","from localhost (unknown [9.115.112.23])\n\tby b03ledav002.gho.boulder.ibm.com (Postfix) with ESMTP id\n\tF3A46136044; Wed, 27 Sep 2017 01:55:18 -0600 (MDT)"],"Date":"Wed, 27 Sep 2017 15:55:17 +0800","From":"Dong Jia Shi ","To":"Halil Pasic ","Mail-Followup-To":"Halil Pasic ,\n\tDong Jia Shi ,\n\tCornelia Huck ,\n\tPierre Morel , qemu-devel@nongnu.org","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","Organization":"(IBM CSL)","X-URL":"http://ibm.com/","User-Agent":"Mutt/1.5.21 (2010-09-15)","X-TM-AS-GCONF":"00","x-cbid":"17092707-0020-0000-0000-00000CC49286","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007800; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000231; SDB=6.00923004; UDB=6.00463976;\n\tIPR=6.00703146; \n\tBA=6.00005608; 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.00017289;\n\tXFM=3.00000015; UTC=2017-09-27 07:55:21","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17092707-0021-0000-0000-00005E4AB163","Message-Id":"<20170927075517.GB5870@bjsdjshi@linux.vnet.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-27_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-1709270108","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 4/9] s390x: refactor error handling for\n\tSSCH and RSCH","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 ,\n\tHalil Pasic , qemu-devel@nongnu.org","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"\"Qemu-devel\"\n\t"}}]