From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Morse Subject: Re: [PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt Date: Tue, 18 Apr 2017 11:51:50 +0100 Message-ID: <58F5EFC6.5070601@arm.com> References: <1490869877-118713-1-git-send-email-xiexiuqi@huawei.com> <1490869877-118713-8-git-send-email-xiexiuqi@huawei.com> <20170413105131.GD24027@leverpostej> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu To: Xiongfeng Wang , Mark Rutland , Xie XiuQi Cc: linux-arm-kernel@lists.infradead.org, wuquanming@huawei.com, kvm@vger.kernel.org, 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, Wang Xiongfeng , shiju.jose@huawei.com, zhengqiang10@huawei.com, kvmarm@lists.cs.columbia.edu, fu.wei@linaro.org, hanjun.guo@linaro.org List-Id: linux-acpi@vger.kernel.org Hi Wang Xiongfeng, On 18/04/17 02:09, Xiongfeng Wang wrote: > I have some confusion about the RAS feature when VHE is enabled. Does RAS spec support > the situation when VHE is enabled. When VHE is disabled, the hyperviosr delegates the error > exception to EL1 by setting HCR_EL2.VSE to 1, and this will inject a virtual SEI into OS. (The ARM-ARM also requires the HCR_EL2.AMO to be set so that physical SError Interrupts are taken to EL2, meaning EL1 can never receive a physical SError) > My understanding is that HCR_EL2.VSE is only used to inject a virtual SEI into EL1. ... mine too ... > But when VHE is enabled, the host OS will run at EL2. We can't inject a virtual SEI into > host OS. I don't know if RAS spec can handle this situation. The host expects to receive physical SError Interrupts. The ARM-ARM doesn't describe a way to inject these as they are generated by the CPU. Am I right in thinking you want this to use SError Interrupts as an APEI notification? (This isn't a CPU thing so the RAS spec doesn't cover this use) This is straightforward for the hyper-visor to implement using Virtual SError. I don't think its not always feasible for the host as Physical SError is routed to EL3 by SCR_EL3.EA, meaning there is no hardware generated SError that can reach EL2. Another APEI notification mechanism may be more appropriate. EL3 may be able to 'fake' an SError by returning into the appropriate EL2 vector if the exception came from EL{0,1}, or from EL2 and PSTATE.A is clear. If the SError came from EL2 and the ESR_EL3.IESB bit is set, we can write an appropriate ESR into DISR. You cant use SError to cover all the possible RAS exceptions. We already have this problem using SEI if PSTATE.A was set and the exception was an imprecise abort from EL2. We can't return to the interrupted context and we can't deliver an SError to EL2 either. Setting SCR_EL3.EA allows firmware to handle these ugly corner cases. Notifying the OS is a separate problem where APEI's SEI may not always be the best choice. Thanks, James From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756689AbdDRKxs (ORCPT ); Tue, 18 Apr 2017 06:53:48 -0400 Received: from foss.arm.com ([217.140.101.70]:55624 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751164AbdDRKwT (ORCPT ); Tue, 18 Apr 2017 06:52:19 -0400 Message-ID: <58F5EFC6.5070601@arm.com> Date: Tue, 18 Apr 2017 11:51:50 +0100 From: James Morse User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: Xiongfeng Wang , Mark Rutland , Xie XiuQi CC: christoffer.dall@linaro.org, marc.zyngier@arm.com, catalin.marinas@arm.com, will.deacon@arm.com, fu.wei@linaro.org, rostedt@goodmis.org, hanjun.guo@linaro.org, shiju.jose@huawei.com, wuquanming@huawei.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, gengdongjiu@huawei.com, linux-acpi@vger.kernel.org, Wang Xiongfeng , zhengqiang10@huawei.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt References: <1490869877-118713-1-git-send-email-xiexiuqi@huawei.com> <1490869877-118713-8-git-send-email-xiexiuqi@huawei.com> <20170413105131.GD24027@leverpostej> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Wang Xiongfeng, On 18/04/17 02:09, Xiongfeng Wang wrote: > I have some confusion about the RAS feature when VHE is enabled. Does RAS spec support > the situation when VHE is enabled. When VHE is disabled, the hyperviosr delegates the error > exception to EL1 by setting HCR_EL2.VSE to 1, and this will inject a virtual SEI into OS. (The ARM-ARM also requires the HCR_EL2.AMO to be set so that physical SError Interrupts are taken to EL2, meaning EL1 can never receive a physical SError) > My understanding is that HCR_EL2.VSE is only used to inject a virtual SEI into EL1. ... mine too ... > But when VHE is enabled, the host OS will run at EL2. We can't inject a virtual SEI into > host OS. I don't know if RAS spec can handle this situation. The host expects to receive physical SError Interrupts. The ARM-ARM doesn't describe a way to inject these as they are generated by the CPU. Am I right in thinking you want this to use SError Interrupts as an APEI notification? (This isn't a CPU thing so the RAS spec doesn't cover this use) This is straightforward for the hyper-visor to implement using Virtual SError. I don't think its not always feasible for the host as Physical SError is routed to EL3 by SCR_EL3.EA, meaning there is no hardware generated SError that can reach EL2. Another APEI notification mechanism may be more appropriate. EL3 may be able to 'fake' an SError by returning into the appropriate EL2 vector if the exception came from EL{0,1}, or from EL2 and PSTATE.A is clear. If the SError came from EL2 and the ESR_EL3.IESB bit is set, we can write an appropriate ESR into DISR. You cant use SError to cover all the possible RAS exceptions. We already have this problem using SEI if PSTATE.A was set and the exception was an imprecise abort from EL2. We can't return to the interrupted context and we can't deliver an SError to EL2 either. Setting SCR_EL3.EA allows firmware to handle these ugly corner cases. Notifying the OS is a separate problem where APEI's SEI may not always be the best choice. Thanks, James From mboxrd@z Thu Jan 1 00:00:00 1970 From: james.morse@arm.com (James Morse) Date: Tue, 18 Apr 2017 11:51:50 +0100 Subject: [PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt In-Reply-To: References: <1490869877-118713-1-git-send-email-xiexiuqi@huawei.com> <1490869877-118713-8-git-send-email-xiexiuqi@huawei.com> <20170413105131.GD24027@leverpostej> Message-ID: <58F5EFC6.5070601@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Wang Xiongfeng, On 18/04/17 02:09, Xiongfeng Wang wrote: > I have some confusion about the RAS feature when VHE is enabled. Does RAS spec support > the situation when VHE is enabled. When VHE is disabled, the hyperviosr delegates the error > exception to EL1 by setting HCR_EL2.VSE to 1, and this will inject a virtual SEI into OS. (The ARM-ARM also requires the HCR_EL2.AMO to be set so that physical SError Interrupts are taken to EL2, meaning EL1 can never receive a physical SError) > My understanding is that HCR_EL2.VSE is only used to inject a virtual SEI into EL1. ... mine too ... > But when VHE is enabled, the host OS will run at EL2. We can't inject a virtual SEI into > host OS. I don't know if RAS spec can handle this situation. The host expects to receive physical SError Interrupts. The ARM-ARM doesn't describe a way to inject these as they are generated by the CPU. Am I right in thinking you want this to use SError Interrupts as an APEI notification? (This isn't a CPU thing so the RAS spec doesn't cover this use) This is straightforward for the hyper-visor to implement using Virtual SError. I don't think its not always feasible for the host as Physical SError is routed to EL3 by SCR_EL3.EA, meaning there is no hardware generated SError that can reach EL2. Another APEI notification mechanism may be more appropriate. EL3 may be able to 'fake' an SError by returning into the appropriate EL2 vector if the exception came from EL{0,1}, or from EL2 and PSTATE.A is clear. If the SError came from EL2 and the ESR_EL3.IESB bit is set, we can write an appropriate ESR into DISR. You cant use SError to cover all the possible RAS exceptions. We already have this problem using SEI if PSTATE.A was set and the exception was an imprecise abort from EL2. We can't return to the interrupted context and we can't deliver an SError to EL2 either. Setting SCR_EL3.EA allows firmware to handle these ugly corner cases. Notifying the OS is a separate problem where APEI's SEI may not always be the best choice. Thanks, James