Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754893AbdLODbY (ORCPT ); Thu, 14 Dec 2017 22:31:24 -0500 Received: from szxga06-in.huawei.com ([45.249.212.32]:36577 "EHLO huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1754792AbdLODbW (ORCPT ); Thu, 14 Dec 2017 22:31:22 -0500 Subject: Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization From: gengdongjiu To: James Morse CC: , , , , , , , , , , , , , , , , , , References: <1510343650-23659-1-git-send-email-gengdongjiu@huawei.com> <1510343650-23659-8-git-send-email-gengdongjiu@huawei.com> <5A0B1334.7060500@arm.com> <4af78739-99da-4056-4db1-f80bfe11081a@huawei.com> <5A283F26.3020507@arm.com> <4b37e86d-eee3-c51e-eceb-5d0c7ad12886@huawei.com> Message-ID: <506cd212-3d16-ba2a-518f-34982bc162fc@huawei.com> Date: Fri, 15 Dec 2017 11:30:57 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <4b37e86d-eee3-c51e-eceb-5d0c7ad12886@huawei.com> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.142.68.147] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2256 Lines: 54 Hi James, On 2017/12/7 14:37, gengdongjiu wrote: >> We need to tackle (1) and (3) separately. For (3) we need some API that lets >> Qemu _trigger_ an SError in the guest, with a specified ESR. But, we don't have >> a way of migrating pending SError yet... which is where I got stuck last time I >> was looking at this. > I understand you most idea. > > But In the Qemu one signal type can only correspond to one behavior, can not correspond to two behaviors, > otherwise Qemu will do not know how to do. > > For the Qemu, if it receives the SIGBUS_MCEERR_AR signal, it will populate the CPER > records and inject a SEA to guest through KVM IOCTL "KVM_SET_ONE_REG"; if receives the SIGBUS_MCEERR_AO > signal, it will record the CPER and trigger a IRQ to notify guest, as shown below: > > SIGBUS_MCEERR_AR trigger Synchronous External Abort. > SIGBUS_MCEERR_AO trigger GPIO IRQ. > > For the SIGBUS_MCEERR_AO and SIGBUS_MCEERR_AR, we have already specify trigger method, which all > > not involve _trigger_ an SError. > > so there is no chance for Qemu to trigger the SError when gets the SIGBUS_MCEERR_A{O,R}. As I explained above: If Qemu received SIGBUS_MCEERR_AR, it will record CPER and trigger Synchronous External Abort; If Qemu received SIGBUS_MCEERR_AO, it will record CPER and trigger GPIO IRQ; So Qemu does not know when to _trigger_ an SError. so here I "return a error" to Qemu if ghes_notify_sei() return failure in [1], if you opposed KVM "return error", do you have a better idea about it? thanks About the way of migrating pending SError, I think it is a separate case, because Qemu still does not know how and when to trigger the SError. [1]: static int kvm_handle_guest_sei(struct kvm_vcpu *vcpu, struct kvm_run *run) { ....................... + case ESR_ELx_AET_UER: /* The error has not been propagated */ + /* + * Userspace only handle the guest SError Interrupt(SEI) if the + * error has not been propagated + */ + run->exit_reason = KVM_EXIT_EXCEPTION; + run->ex.exception = ESR_ELx_EC_SERROR; + run->ex.error_code = KVM_SEI_SEV_RECOVERABLE; + return 0; ....................... } >