From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiongfeng Wang Subject: Re: [PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt Date: Tue, 9 May 2017 10:16:32 +0800 Message-ID: <4cfa4f66-e9a2-fd52-fb64-b2510bcdf1d8@huawei.com> References: <1490869877-118713-1-git-send-email-xiexiuqi@huawei.com> <1490869877-118713-8-git-send-email-xiexiuqi@huawei.com> <20170413105131.GD24027@leverpostej> <58F5EFC6.5070601@arm.com> <58F876EB.2020805@arm.com> <2bb41d98-553f-1361-e497-4095ddd501d0@huawei.com> <58FE328E.7030106@arm.com> <5910AA92.2010106@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5910AA92.2010106@arm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: James Morse Cc: Mark Rutland , wuquanming@huawei.com, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, Xie XiuQi , marc.zyngier@arm.com, catalin.marinas@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, rostedt@goodmis.org, gengdongjiu@huawei.com, linux-acpi@vger.kernel.org, fu.wei@linaro.org, shiju.jose@huawei.com, zhengqiang10@huawei.com, kvmarm@lists.cs.columbia.edu, christoffer.dall@linaro.org, hanjun.guo@linaro.org List-Id: linux-acpi@vger.kernel.org Hi James, On 2017/5/9 1:27, James Morse wrote: > Hi Xiongfeng Wang, > > On 28/04/17 03:55, Xiongfeng Wang wrote: >>>>>> It is ok to just ignore the process following the ESB instruction in el0_sync, because the process will be sent SIGBUS signal. >>>> >>>> I don't understand. How will Linux know the process caused an error if we >>>> neither take an SError nor read DISR_EL1 after an ESB? > >> I think there may be some misunderstanding here. The ESB instruction is placed in kernel_entry >> of el0_sync and el0_irq. For the el0_sync, such as an syscall from userspace, after ESB is executed, >> we check whether DISR.A is set. If it is not set, we go on to process the syscall. If it is set, we >> jump to sError vector and then just eret. > > Ah, this looks like an early optimisation! > > We can't assume that the SError will result in the processing being killed, the > AET bits of the SError ISS Encoding (page D7-2284 of ARM-ARM DDI0487B.a), has a > 'corrected' error encoding. > For these I would expect the SError-vector C code to do nothing and return to > where it came from. In this case the syscall should still be run. > Yes, it makes sense, so we should add a return value for the do_sei handler. Thanks, Wang Xiongfeng From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754613AbdEICWA (ORCPT ); Mon, 8 May 2017 22:22:00 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:6271 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753697AbdEICV6 (ORCPT ); Mon, 8 May 2017 22:21:58 -0400 Subject: Re: [PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt To: James Morse References: <1490869877-118713-1-git-send-email-xiexiuqi@huawei.com> <1490869877-118713-8-git-send-email-xiexiuqi@huawei.com> <20170413105131.GD24027@leverpostej> <58F5EFC6.5070601@arm.com> <58F876EB.2020805@arm.com> <2bb41d98-553f-1361-e497-4095ddd501d0@huawei.com> <58FE328E.7030106@arm.com> <5910AA92.2010106@arm.com> CC: Mark Rutland , Xie XiuQi , , , , , , , , , , , , , , , , From: Xiongfeng Wang Message-ID: <4cfa4f66-e9a2-fd52-fb64-b2510bcdf1d8@huawei.com> Date: Tue, 9 May 2017 10:16:32 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <5910AA92.2010106@arm.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.32.209] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59112797.007E,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f19f44663983382a45fed4875de11eac Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi James, On 2017/5/9 1:27, James Morse wrote: > Hi Xiongfeng Wang, > > On 28/04/17 03:55, Xiongfeng Wang wrote: >>>>>> It is ok to just ignore the process following the ESB instruction in el0_sync, because the process will be sent SIGBUS signal. >>>> >>>> I don't understand. How will Linux know the process caused an error if we >>>> neither take an SError nor read DISR_EL1 after an ESB? > >> I think there may be some misunderstanding here. The ESB instruction is placed in kernel_entry >> of el0_sync and el0_irq. For the el0_sync, such as an syscall from userspace, after ESB is executed, >> we check whether DISR.A is set. If it is not set, we go on to process the syscall. If it is set, we >> jump to sError vector and then just eret. > > Ah, this looks like an early optimisation! > > We can't assume that the SError will result in the processing being killed, the > AET bits of the SError ISS Encoding (page D7-2284 of ARM-ARM DDI0487B.a), has a > 'corrected' error encoding. > For these I would expect the SError-vector C code to do nothing and return to > where it came from. In this case the syscall should still be run. > Yes, it makes sense, so we should add a return value for the do_sei handler. Thanks, Wang Xiongfeng From mboxrd@z Thu Jan 1 00:00:00 1970 From: wangxiongfeng2@huawei.com (Xiongfeng Wang) Date: Tue, 9 May 2017 10:16:32 +0800 Subject: [PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt In-Reply-To: <5910AA92.2010106@arm.com> References: <1490869877-118713-1-git-send-email-xiexiuqi@huawei.com> <1490869877-118713-8-git-send-email-xiexiuqi@huawei.com> <20170413105131.GD24027@leverpostej> <58F5EFC6.5070601@arm.com> <58F876EB.2020805@arm.com> <2bb41d98-553f-1361-e497-4095ddd501d0@huawei.com> <58FE328E.7030106@arm.com> <5910AA92.2010106@arm.com> Message-ID: <4cfa4f66-e9a2-fd52-fb64-b2510bcdf1d8@huawei.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi James, On 2017/5/9 1:27, James Morse wrote: > Hi Xiongfeng Wang, > > On 28/04/17 03:55, Xiongfeng Wang wrote: >>>>>> It is ok to just ignore the process following the ESB instruction in el0_sync, because the process will be sent SIGBUS signal. >>>> >>>> I don't understand. How will Linux know the process caused an error if we >>>> neither take an SError nor read DISR_EL1 after an ESB? > >> I think there may be some misunderstanding here. The ESB instruction is placed in kernel_entry >> of el0_sync and el0_irq. For the el0_sync, such as an syscall from userspace, after ESB is executed, >> we check whether DISR.A is set. If it is not set, we go on to process the syscall. If it is set, we >> jump to sError vector and then just eret. > > Ah, this looks like an early optimisation! > > We can't assume that the SError will result in the processing being killed, the > AET bits of the SError ISS Encoding (page D7-2284 of ARM-ARM DDI0487B.a), has a > 'corrected' error encoding. > For these I would expect the SError-vector C code to do nothing and return to > where it came from. In this case the syscall should still be run. > Yes, it makes sense, so we should add a return value for the do_sei handler. Thanks, Wang Xiongfeng