Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752646AbdCFDkm (ORCPT ); Sun, 5 Mar 2017 22:40:42 -0500 Received: from szxga03-in.huawei.com ([45.249.212.189]:3465 "EHLO dggrg03-dlp.huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752543AbdCFDkk (ORCPT ); Sun, 5 Mar 2017 22:40:40 -0500 Subject: Re: [PATCH V11 10/10] arm/arm64: KVM: add guest SEA support To: Marc Zyngier , James Morse References: <1487712121-16688-1-git-send-email-tbaicar@codeaurora.org> <1487712121-16688-11-git-send-email-tbaicar@codeaurora.org> <58B43092.6040401@arm.com> <3df82a7b-1a32-e2d7-ae78-7132a4eab1a0@huawei.com> <58B57941.3000703@arm.com> <4ff98823-d6f0-eb2e-4b98-f6d5e255f6c3@huawei.com> <6d0fa5a5-bcbf-38b8-45ac-d645220ee9e2@arm.com> CC: , , , , , , Tyler Baicar , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , From: Xiongfeng Wang Message-ID: <8d020d81-d697-f05e-dbce-3a5a02c7c7db@huawei.com> Date: Mon, 6 Mar 2017 11:38:46 +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: <6d0fa5a5-bcbf-38b8-45ac-d645220ee9e2@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.0A090202.58BCDA03.0050,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: 64ab332dae73f577bd02200ccc7c18e5 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2080 Lines: 46 Hi Marc, On 2017/3/2 17:39, Marc Zyngier wrote: > On 01/03/17 02:31, Xiongfeng Wang wrote: > > [lot of things] > >> If an SEA is injected into guest OS, the guest OS will jump to the SEA >> exception entry when the context switched to guest OS. And the CPSR and >> FAR_EL1 are recovered according to the content of vcpu. Then the guest >> OS can signal a process or panic. If another guest process read the >> error data, another SEA will be generated and it will be single too. >> >> Without QEMU involved, the drawback is that no APEI table can be mocked >> up in guest OS, and no memory_failure() will be called. So the memory of >> error data will be released into buddy system and assigned to another >> process. If the error was caused by instantaneous radiation or >> electromagnetic, the memory is usable again if it is written with a >> correct data. If the memory has wore out and a correct data is written, >> the ECC error may occurs again with high possibility. Before a 2-bit ECC >> error is reported, much more 1-bit errors will be reported. This is >> report to host os, the host os can determine the memory node has worn >> out and hot-plug out the memory node, and guest os may be terminated if >> its memory data can't be migrated. >> >> Of course, it is better to get QEMU involved, so the memory_failure can >> be executed in guest OS. But before that implemented, can we add SEA >> injection in kvm_handle_guest_abort()? > > No. I will strongly object to that. This is a platform decision to > forward SEAs, not an architectural one. The core KVM code is only > concerned about implementing the ARM architecture, and not something > that is firmware dependent. > Thanks for the reply! I'm not sure if there exists some misunderstanding here. I was saying that APEI stuff is not included in the core KVM code, but SEA injection can be included, just like the SEI injection in the core KVM code. Yes, APEI is firmware dependent, but I think SEA is not. And the processing for SEA doesn't depend on whether APEI is implemented. Thanks, Wang Xiongfeng .