From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758199AbdCUTt7 (ORCPT ); Tue, 21 Mar 2017 15:49:59 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:37373 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757684AbdCUTrT (ORCPT ); Tue, 21 Mar 2017 15:47:19 -0400 Date: Tue, 21 Mar 2017 20:39:33 +0100 From: Christoffer Dall To: James Morse Cc: gengdongjiu , xiexiuqi@huawei.com, Marc Zyngier , catalin.marinas@arm.com, will.deacon@arm.com, christoffer.dall@linaro.org, rkrcmar@redhat.com, suzuki.poulose@arm.com, andre.przywara@arm.com, mark.rutland@arm.com, vladimir.murzin@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, wangxiongfeng2@huawei.com, wuquanming@huawei.com, huangshaoyu@huawei.com Subject: Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Message-ID: <20170321193933.GB31111@cbox> References: <1489996534-8270-1-git-send-email-gengdongjiu@huawei.com> <7055772d-2a20-6e0c-2bf8-204bc9ef52a5@arm.com> <22fb583f-a33e-15f8-a059-fb112b27dd4f@arm.com> <58CFF058.8020205@arm.com> <76795e20-2f20-1e54-cfa5-7444f28b18ee@huawei.com> <20170321113428.GC15920@cbox> <58D17AF0.2010802@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58D17AF0.2010802@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [resending as clear text - I thought GMail supported that - sorry] On Tue, Mar 21, 2017 at 07:11:44PM +0000, James Morse wrote: > Hi Christoffer, > > On 21/03/17 11:34, Christoffer Dall wrote: > > On Tue, Mar 21, 2017 at 02:32:29PM +0800, gengdongjiu wrote: > >> On 2017/3/20 23:08, James Morse wrote: > >>>>>> On 20/03/17 07:55, Dongjiu Geng wrote: > >>>>>>> In the RAS implementation, hardware pass the virtual SEI > >>>>>>> syndrome information through the VSESR_EL2, so set the virtual > >>>>>>> SEI syndrome using physical SEI syndrome el2_elr to pass to > >>>>>>> the guest OS > >>> > >>> How does this work with firmware first? > >> > >> I explained it in previous mail about the work flow. > > > > When delivering and reporting SEIs to the VM, should this happen > > directly to the OS running in the VM, or to the guest firmware (e.g. > > UEFI) running in the VM as well? > > 'firmware first' is the ACPI specs name for x86's BIOS or management-mode > handling the error. On arm64 we have multiple things called firmware, so the > name might be more confusing than helpful. > > As far as I understand it, firmware here refers to the secure-world and EL3. > Something like ATF can use SCR_EL3.EA to claim SErrors and external aborts, > routing them to EL3 where secure platform specific firmware generates CPER records. > For a guest, Qemu takes the role of this EL3-firmware. > Thanks for the clarification. So UEFI in the VM would not be involved in this at all? My confusion here comes from not thinking about QEMU or KVM as firmware, but as the machine, so it would be sort of like the functionality is baked into hardware rather than firmware. Note that to the VM, the environment will look like hardware without EL3 and without a secure world, so any software assuming there's something 'hidden' behind the available non-secure modes must not decide to disable features if discovering the lack of a secure world. Thanks, -Christoffer From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Date: Tue, 21 Mar 2017 20:39:33 +0100 Message-ID: <20170321193933.GB31111@cbox> References: <1489996534-8270-1-git-send-email-gengdongjiu@huawei.com> <7055772d-2a20-6e0c-2bf8-204bc9ef52a5@arm.com> <22fb583f-a33e-15f8-a059-fb112b27dd4f@arm.com> <58CFF058.8020205@arm.com> <76795e20-2f20-1e54-cfa5-7444f28b18ee@huawei.com> <20170321113428.GC15920@cbox> <58D17AF0.2010802@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Marc Zyngier , catalin.marinas@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, gengdongjiu , wangxiongfeng2@huawei.com, wuquanming@huawei.com, huangshaoyu@huawei.com, linux-arm-kernel@lists.infradead.org, andre.przywara@arm.com, kvmarm@lists.cs.columbia.edu To: James Morse Return-path: Content-Disposition: inline In-Reply-To: <58D17AF0.2010802@arm.com> 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 List-Id: kvm.vger.kernel.org [resending as clear text - I thought GMail supported that - sorry] On Tue, Mar 21, 2017 at 07:11:44PM +0000, James Morse wrote: > Hi Christoffer, > > On 21/03/17 11:34, Christoffer Dall wrote: > > On Tue, Mar 21, 2017 at 02:32:29PM +0800, gengdongjiu wrote: > >> On 2017/3/20 23:08, James Morse wrote: > >>>>>> On 20/03/17 07:55, Dongjiu Geng wrote: > >>>>>>> In the RAS implementation, hardware pass the virtual SEI > >>>>>>> syndrome information through the VSESR_EL2, so set the virtual > >>>>>>> SEI syndrome using physical SEI syndrome el2_elr to pass to > >>>>>>> the guest OS > >>> > >>> How does this work with firmware first? > >> > >> I explained it in previous mail about the work flow. > > > > When delivering and reporting SEIs to the VM, should this happen > > directly to the OS running in the VM, or to the guest firmware (e.g. > > UEFI) running in the VM as well? > > 'firmware first' is the ACPI specs name for x86's BIOS or management-mode > handling the error. On arm64 we have multiple things called firmware, so the > name might be more confusing than helpful. > > As far as I understand it, firmware here refers to the secure-world and EL3. > Something like ATF can use SCR_EL3.EA to claim SErrors and external aborts, > routing them to EL3 where secure platform specific firmware generates CPER records. > For a guest, Qemu takes the role of this EL3-firmware. > Thanks for the clarification. So UEFI in the VM would not be involved in this at all? My confusion here comes from not thinking about QEMU or KVM as firmware, but as the machine, so it would be sort of like the functionality is baked into hardware rather than firmware. Note that to the VM, the environment will look like hardware without EL3 and without a secure world, so any software assuming there's something 'hidden' behind the available non-secure modes must not decide to disable features if discovering the lack of a secure world. Thanks, -Christoffer From mboxrd@z Thu Jan 1 00:00:00 1970 From: cdall@linaro.org (Christoffer Dall) Date: Tue, 21 Mar 2017 20:39:33 +0100 Subject: [PATCH] kvm: pass the virtual SEI syndrome to guest OS In-Reply-To: <58D17AF0.2010802@arm.com> References: <1489996534-8270-1-git-send-email-gengdongjiu@huawei.com> <7055772d-2a20-6e0c-2bf8-204bc9ef52a5@arm.com> <22fb583f-a33e-15f8-a059-fb112b27dd4f@arm.com> <58CFF058.8020205@arm.com> <76795e20-2f20-1e54-cfa5-7444f28b18ee@huawei.com> <20170321113428.GC15920@cbox> <58D17AF0.2010802@arm.com> Message-ID: <20170321193933.GB31111@cbox> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org [resending as clear text - I thought GMail supported that - sorry] On Tue, Mar 21, 2017 at 07:11:44PM +0000, James Morse wrote: > Hi Christoffer, > > On 21/03/17 11:34, Christoffer Dall wrote: > > On Tue, Mar 21, 2017 at 02:32:29PM +0800, gengdongjiu wrote: > >> On 2017/3/20 23:08, James Morse wrote: > >>>>>> On 20/03/17 07:55, Dongjiu Geng wrote: > >>>>>>> In the RAS implementation, hardware pass the virtual SEI > >>>>>>> syndrome information through the VSESR_EL2, so set the virtual > >>>>>>> SEI syndrome using physical SEI syndrome el2_elr to pass to > >>>>>>> the guest OS > >>> > >>> How does this work with firmware first? > >> > >> I explained it in previous mail about the work flow. > > > > When delivering and reporting SEIs to the VM, should this happen > > directly to the OS running in the VM, or to the guest firmware (e.g. > > UEFI) running in the VM as well? > > 'firmware first' is the ACPI specs name for x86's BIOS or management-mode > handling the error. On arm64 we have multiple things called firmware, so the > name might be more confusing than helpful. > > As far as I understand it, firmware here refers to the secure-world and EL3. > Something like ATF can use SCR_EL3.EA to claim SErrors and external aborts, > routing them to EL3 where secure platform specific firmware generates CPER records. > For a guest, Qemu takes the role of this EL3-firmware. > Thanks for the clarification. So UEFI in the VM would not be involved in this at all? My confusion here comes from not thinking about QEMU or KVM as firmware, but as the machine, so it would be sort of like the functionality is baked into hardware rather than firmware. Note that to the VM, the environment will look like hardware without EL3 and without a secure world, so any software assuming there's something 'hidden' behind the available non-secure modes must not decide to disable features if discovering the lack of a secure world. Thanks, -Christoffer