From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755371AbdC1Ks6 (ORCPT ); Tue, 28 Mar 2017 06:48:58 -0400 Received: from foss.arm.com ([217.140.101.70]:46312 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754837AbdC1Ks5 (ORCPT ); Tue, 28 Mar 2017 06:48:57 -0400 Message-ID: <58DA3F68.6090901@arm.com> Date: Tue, 28 Mar 2017 11:48:08 +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: Christoffer Dall 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, Achin Gupta , Leif.Lindholm@linaro.com Subject: Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS 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> <20170321193933.GB31111@cbox> In-Reply-To: <20170321193933.GB31111@cbox> 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 Christoffer, (CC: Leif and Achin who know more about how UEFI fits into this picture) On 21/03/17 19:39, Christoffer Dall wrote: > On Tue, Mar 21, 2017 at 07:11:44PM +0000, James Morse wrote: >> 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? On the host, part of UEFI is involved to generate the CPER records. In a guest?, I don't know. Qemu could generate the records, or drive some other component to do it. Leif and Achin are the people with the UEFI/bigger picture. > 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, James From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Morse Subject: Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Date: Tue, 28 Mar 2017 11:48:08 +0100 Message-ID: <58DA3F68.6090901@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> <20170321193933.GB31111@cbox> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Leif.Lindholm@linaro.com, kvm@vger.kernel.org, Marc Zyngier , catalin.marinas@arm.com, Achin Gupta , 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: Christoffer Dall Return-path: In-Reply-To: <20170321193933.GB31111@cbox> 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 Hi Christoffer, (CC: Leif and Achin who know more about how UEFI fits into this picture) On 21/03/17 19:39, Christoffer Dall wrote: > On Tue, Mar 21, 2017 at 07:11:44PM +0000, James Morse wrote: >> 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? On the host, part of UEFI is involved to generate the CPER records. In a guest?, I don't know. Qemu could generate the records, or drive some other component to do it. Leif and Achin are the people with the UEFI/bigger picture. > 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, James From mboxrd@z Thu Jan 1 00:00:00 1970 From: james.morse@arm.com (James Morse) Date: Tue, 28 Mar 2017 11:48:08 +0100 Subject: [PATCH] kvm: pass the virtual SEI syndrome to guest OS In-Reply-To: <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> <20170321193933.GB31111@cbox> Message-ID: <58DA3F68.6090901@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Christoffer, (CC: Leif and Achin who know more about how UEFI fits into this picture) On 21/03/17 19:39, Christoffer Dall wrote: > On Tue, Mar 21, 2017 at 07:11:44PM +0000, James Morse wrote: >> 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? On the host, part of UEFI is involved to generate the CPER records. In a guest?, I don't know. Qemu could generate the records, or drive some other component to do it. Leif and Achin are the people with the UEFI/bigger picture. > 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, James