From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751527AbdB1Gdp (ORCPT ); Tue, 28 Feb 2017 01:33:45 -0500 Received: from lhrrgout.huawei.com ([194.213.3.17]:11188 "EHLO lhrrgout.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751395AbdB1Gdm (ORCPT ); Tue, 28 Feb 2017 01:33:42 -0500 Subject: Re: [PATCH V11 10/10] arm/arm64: KVM: add guest SEA support To: 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> CC: , , , , , , Tyler Baicar , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , From: Xiongfeng Wang Message-ID: <3df82a7b-1a32-e2d7-ae78-7132a4eab1a0@huawei.com> Date: Tue, 28 Feb 2017 14:25:07 +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: <58B43092.6040401@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.58B517EA.0346,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 X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58B51904.0138,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ac041350f7de1384f7bf8c0c8ce518f6 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi James, On 2017/2/27 21:58, James Morse wrote: > Hi Wang Xiongfeng, > > On 25/02/17 07:15, Xiongfeng Wang wrote: >> On 2017/2/22 5:22, Tyler Baicar wrote: >>> Currently external aborts are unsupported by the guest abort >>> handling. Add handling for SEAs so that the host kernel reports >>> SEAs which occur in the guest kernel. > >>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c >>> index a5265ed..04f1dd50 100644 >>> --- a/arch/arm/kvm/mmu.c >>> +++ b/arch/arm/kvm/mmu.c >>> @@ -1444,8 +1445,21 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run) >>> >>> /* Check the stage-2 fault is trans. fault or write fault */ >>> fault_status = kvm_vcpu_trap_get_fault_type(vcpu); >>> - if (fault_status != FSC_FAULT && fault_status != FSC_PERM && >>> - fault_status != FSC_ACCESS) { >>> + >>> + /* The host kernel will handle the synchronous external abort. There >>> + * is no need to pass the error into the guest. >>> + */ > >> Can we inject an sea into the guest, so that the guest can kill the >> application which causes the error if the guest won't be terminated >> later. I'm not sure whether ghes_handle_memory_failure() called in >> ghes_do_proc() will kill the qemu process. I think it only kill user >> processes marked with PF_MCE_PROCESS & PF_MCE_EARLY. > > My understanding is the pages will get unmapped and recovered where possible > (e.g. re-read from disk), the user space process will get SIGBUS/SIGSEV when it > next tries to access that page, which could be some time later. > These flags in find_early_kill_thread() are a way to make the memory-failure > code signal the process early, before it does any recovery. The 'MCE' makes me > think its x86 specific. > (early and late are described more in [0]) > > > Guests are a special case as QEMU may never access the faulty memory itself, so > it won't receive the 'late' signal. It looks like ARM/arm64 KVM lacks support > for KVM_PFN_ERR_HWPOISON which sends SIGBUS from KVM's fault-handling code. I > have patches to add support for this which I intend to send at rc1. > > [0] suggests 'KVM qemu' sets these MCE flags to take the 'early' path, but given > x86s KVM_PFN_ERR_HWPOISON, this may be out of date. > > > Either way, once QEMU gets a signal indicating the virtual address, it can > generate its own APEI CPER records and use the KVM APIs to mock up an > Synchronous External Abort, (or inject an IRQ or run the vcpu waiting for the > guest's polling thread to come round, whichever was described to the guest via > the HEST/GHES tables). > > We can't hand the APEI CPER records we have in the kernel to the guest, as they > hold a host physical address, and maybe a host virtual address. We don't know > where in guest memory we could write new APEI CPER records as these locations > have to be reserved in the guests-UEFI memory map, and only QEMU knows where > they are. > > To deliver RAS events to a guest we have to get QEMU involved. Thanks for your reply! I have another idea about the handling procedure of SEA. Can we divide the SEA handing procedure into two procedures? The first procedure does the more urgent work, including sending SIGBUS to user process or panic, just as PATCH 04/10 does. The second procedure does the APEI analysis work, including calling memory_failure. The second procedure is executed when actual errors detected in memory, such as a 2-bit ECC error is detected on memory read or write, in which case, a fault handling interrupt is generated by the memory controller, as RAS Extension specification says. We can route this fault handling interrupt into EL3. After BIOS has filled the HEST table, it can notify OS with an IRQ. And the second procedure is executed in the IRQ handler. The notification type of HEST/GHES tables is GSIV. When uncorrectable data error is detected on write data, a fault handling interrupt is generated, and no SEA is generated, as RAS extension specification 6.4.4 says. In this situation, the second procedure should be executed since error occurs in memory. In ARM/arm64 KVM situation, when an SEA takes place, an SEA is injected into guest os directly in kvm_handle_guest_abort(). And the guest os can execute the first procedure. When the host OS executes the second procedure and analyses the HEST table, it sends SIGBUS to qemu process in memory_failure(). And the qemu process can mock up a HEST table with IPA of the error data. Then the qemu process can notify the guest OS with an IRQ, and the second procedure is executed in guest OS. Is this idea reasonable? Thanks! Wang Xiongfeng