Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751412AbdIMHxO (ORCPT ); Wed, 13 Sep 2017 03:53:14 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:6463 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750931AbdIMHxM (ORCPT ); Wed, 13 Sep 2017 03:53:12 -0400 Subject: Re: [PATCH v11 6/6] target-arm: kvm64: Handle SError interrupt for the guest OS To: Peter Maydell , References: <0184EA26B2509940AA629AE1405DD7F2015FE17F@DGGEMA503-MBX.china.huawei.com> CC: "Michael S. Tsirkin" , Igor Mammedov , Zhaoshenglong , "Paolo Bonzini" , QEMU Developers , qemu-arm , kvm-devel , "edk2-devel@lists.01.org" , Christoffer Dall , Marc Zyngier , "Will Deacon" , James Morse , Tyler Baicar , Ard Biesheuvel , "Ingo Molnar" , "bp@suse.de" , Shiju Jose , "zjzhang@codeaurora.org" , arm-mail-list , "kvmarm@lists.cs.columbia.edu" , "lkml - Kernel Mailing List" , "linux-acpi@vger.kernel.org" , "devel@acpica.org" , "John Garry" , Jonathan Cameron , Shameerali Kolothum Thodi , huangdaode , "Wangzhou (B)" , Huangshaoyu , Wuquanming , Linuxarm , "Zhengqiang (turing)" From: gengdongjiu Message-ID: <5552cf68-b998-686b-8e7e-710399c2b014@huawei.com> Date: Wed, 13 Sep 2017 15:52:14 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.142.68.147] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59B8E3C2.00BF,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: 15ca247d2cce4cb8bdac82ce9979ed6f Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1668 Lines: 36 On 2017/9/12 0:39, Peter Maydell wrote: >>>> + return kvm_vcpu_ioctl(CPU(cpu), KVM_ARM_SEI, &syndrome); >>> This looks odd. If we don't have the RAS extension why do we need to do anything at all here ? >> This is because Qemu may need to support non-RAS extension as discussed with ARM James before. >> That is to say host hardware CPU does not support RAS, but guest supports. >> That is under discussion. >> When host hardware supports RAS, specify the syndrome to a valid value, otherwise, set it to 0. > If the guest CPU doesn't support the RAS extension then we have > no mechanism for delivering it a notification about the > memory problem at all, so setting the syndrome to anything > doesn't make sense. > > I'm not sure what you should do in the case of "host > supports telling us about a memory problem and has > done so, but guest does not support being told about it", > but I'm pretty sure it shouldn't be this. Hi peter, thanks for the comments. in short, if the hardware CPU does not support RAS extension, do you think whether the Qemu or guest OS needs to support RAS(generate APEI table / record CPER / Error recovery). CC James, Hi James, you ever have below comments: ----------------------------------------------------------------------- But you can use APEI in a guest on CPUs without the RAS extensions: the host may signal memory errors to Qemu for any number of reasons. ------------------------------------------------------------------ in fact, I have a concern about it. If CPU without the RAS extension, the host should not deliver the sigbus. in which case in your test that host still deliver sigbus without RAS?