From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1758696AbdCVCsW (ORCPT <rfc822;w@1wt.eu>);
        Tue, 21 Mar 2017 22:48:22 -0400
Received: from szxga01-in.huawei.com ([45.249.212.187]:4779 "EHLO
        dggrg01-dlp.huawei.com" rhost-flags-OK-FAIL-OK-FAIL)
        by vger.kernel.org with ESMTP id S1757696AbdCVCsT (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 21 Mar 2017 22:48:19 -0400
Subject: Re: [PATCH V11 10/10] arm/arm64: KVM: add guest SEA support
To: James Morse <james.morse@arm.com>, <xiexiuqi@huawei.com>,
        <gengdongjiu@huawei.com>, <punit.agrawal@arm.com>
References: <1487712121-16688-1-git-send-email-tbaicar@codeaurora.org>
 <1487712121-16688-11-git-send-email-tbaicar@codeaurora.org>
 <df6ba5dc-d93f-925a-46bf-1e1e209d17f3@huawei.com> <58B43092.6040401@arm.com>
CC: <mark.rutland@arm.com>, <linux-efi@vger.kernel.org>,
        <kvm@vger.kernel.org>, <rkrcmar@redhat.com>,
        <matt@codeblueprint.co.uk>, <catalin.marinas@arm.com>,
        Tyler Baicar <tbaicar@codeaurora.org>, <will.deacon@arm.com>,
        <robert.moore@intel.com>, <paul.gortmaker@windriver.com>,
        <lv.zheng@intel.com>, <kvmarm@lists.cs.columbia.edu>,
        <fu.wei@linaro.org>, <tn@semihalf.com>, <zjzhang@codeaurora.org>,
        <linux@armlinux.org.uk>, <linux-acpi@vger.kernel.org>,
        <eun.taik.lee@samsung.com>, <shijie.huang@arm.com>,
        <labbott@redhat.com>, <lenb@kernel.org>, <harba@codeaurora.org>,
        <Suzuki.Poulose@arm.com>, <marc.zyngier@arm.com>,
        <john.garry@huawei.com>, <rostedt@goodmis.org>, <nkaje@codeaurora.org>,
        <sandeepa.s.prabhu@gmail.com>, <linux-arm-kernel@lists.infradead.org>,
        <devel@acpica.org>, <rjw@rjwysocki.net>, <rruigrok@codeaurora.org>,
        <linux-kernel@vger.kernel.org>, <astone@redhat.com>,
        <hanjun.guo@linaro.org>, <joe@perches.com>, <pbonzini@redhat.com>,
        <akpm@linux-foundation.org>, <bristot@redhat.com>,
        <christoffer.dall@linaro.org>, <shiju.jose@huawei.com>
From: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Message-ID: <6eee7a67-808e-8712-2ec2-593eac52d921@huawei.com>
Date: Wed, 22 Mar 2017 10:46:59 +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.0A020201.58D1E5C8.0003,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: 34ce478640b14fa083622312f58bbace
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi James,


> 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).
> 

I have another confusion about the SIGBUS signal. Can QEMU always get a SIGBUS when needed.
I know one circumstance which will send SIGBUS. The ghes_handle_memory_failure() in
ghes_do_proc() will send SIGBUS to QEMU, but this only happens when there exists memory section
in ghes, that is the section type is CPER_SEC_PLATFORM_MEM.
Suppose this case, an load  error in guest application causes an SEA, and the firmware take it.
The firmware begin to scan the error record and fill the ghes. But the error record in memory node
has been read by other handler. The firmware won't add memory section in ghes, so
ghes_handle_memory_failure() won't be called.
I mean that we may not rely on ghes_handle_memory_failure() to send SIGBUS to QEMU. Whether we should
add some other code to send SIGBUS in handle_guest_abort(). I don't know whether the ARM/arm64
 KVM_PFN_ERR_HWPOISON you mentioned above will cover all the cases.

Thanks,

Wang Xiongfeng
.