Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756432AbdIHO4R (ORCPT ); Fri, 8 Sep 2017 10:56:17 -0400 Received: from mail-wr0-f172.google.com ([209.85.128.172]:37561 "EHLO mail-wr0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756232AbdIHO4P (ORCPT ); Fri, 8 Sep 2017 10:56:15 -0400 X-Google-Smtp-Source: ADKCNb5g+n+oLA5Rcdyn7xHj3avA0ytQ7mc2VVnmHdK012ZwYxPX6eHmHRMt1VJ6S3B49/mhEjzyT4T0HEiM/YT8VnY= MIME-Version: 1.0 In-Reply-To: <0184EA26B2509940AA629AE1405DD7F2015F5973@DGGEMA503-MBX.china.huawei.com> References: <0184EA26B2509940AA629AE1405DD7F2015F5973@DGGEMA503-MBX.china.huawei.com> From: Peter Maydell Date: Fri, 8 Sep 2017 15:55:53 +0100 Message-ID: Subject: Re: [PATCH v11 4/6] target-arm: kvm64: detect guest RAS EXTENSION feature To: gengdongjiu 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)" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1223 Lines: 28 On 8 September 2017 at 15:26, gengdongjiu wrote: >> Shouldn't we need to also tell the kernel that we actually want >> it to expose RAS to the guest? Compare the PMU code in this function, >> where we set a kvm_init_features bit to do this. > In the PMU code, it indeed sets a kvm_init_features bit. Here ARM > James has a concern that we are depend on the host CPU RAS extension, > He means that if userspace receives the SIGBUS delivered by host > memory_failure(), user space should record the CPER for guest > and handling the error regardless whether host CPU supports RAS > extension. But I think if user space receives the SIGBUS signal, > that means > host CPU RAS module detects the error or CPU consumes the poison > data, thus we should check whether physical CPU support RAS extension. I don't understand what you have in mind here. If the host does not support the CPU RAS extension then we should never get a SIGBUS in the first place. In any case this doesn't seem relevant to the question of whether it should be optional to expose the RAS extension to the *guest*. Even if the host does support RAS, you should be able to run a VM that knows nothing about RAS. thanks -- PMM