Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754298AbdHZCuc (ORCPT ); Fri, 25 Aug 2017 22:50:32 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:4579 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754066AbdHZCub (ORCPT ); Fri, 25 Aug 2017 22:50:31 -0400 Subject: Re: [PATCH v11 2/6] ACPI: Add APEI GHES Table Generation support To: Shannon Zhao , , , , , , , , , , , , , , , , , , , , , , , , , , , , , References: <1503066227-18251-1-git-send-email-gengdongjiu@huawei.com> <1503066227-18251-3-git-send-email-gengdongjiu@huawei.com> <599ECE95.10205@huawei.com> <9a878b42-c480-2c7b-0f04-202193d8c56b@huawei.com> <59A0C9FE.5010204@huawei.com> CC: , , , From: gengdongjiu Message-ID: <27894653-ff09-7839-a46d-b41b9ee8ae48@huawei.com> Date: Sat, 26 Aug 2017 10:49:44 +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: <59A0C9FE.5010204@huawei.com> Content-Type: text/plain; charset="windows-1252" 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.0A090203.59A0E1DF.001C,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: c402118da617b6014ffafdba62dacbd2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2893 Lines: 70 Hi Shannon, On 2017/8/26 9:08, Shannon Zhao wrote: > > > On 2017/8/25 19:20, gengdongjiu wrote: >>>> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c >>>>>> index 3d78ff6..def1ec1 100644 >>>>>> --- a/hw/arm/virt-acpi-build.c >>>>>> +++ b/hw/arm/virt-acpi-build.c >>>>>> @@ -45,6 +45,7 @@ >>>>>> #include "hw/arm/virt.h" >>>>>> #include "sysemu/numa.h" >>>>>> #include "kvm_arm.h" >>>>>> +#include "hw/acpi/hest_ghes.h" >>>>>> >>>>>> #define ARM_SPI_BASE 32 >>>>>> #define ACPI_POWER_BUTTON_DEVICE "PWRB" >>>>>> @@ -771,6 +772,9 @@ void virt_acpi_build(VirtMachineState *vms, AcpiBuildTables *tables) >>>>>> acpi_add_table(table_offsets, tables_blob); >>>>>> build_spcr(tables_blob, tables->linker, vms); >>>>>> >>>>>> + acpi_add_table(table_offsets, tables_blob); >>>>>> + ghes_build_acpi(tables_blob, tables->hardware_errors, tables->linker); >>>>>> + >>>> So we add this table unconditionally. Is there any bad impact if QEMU >>>> runs on old kvm? Does it need to check whether KVM supports RAS? >> this table is added before guest OS boot. so can not use KVM to check it. > No, we can check the RAS capability when we create vcpus like you done > in another patch ans can use that in table generation. understand your meaning. ARM James ever have below comments about the table generation. ---------------------------------------------------------------------------------- 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, user-space shouldn't care how it knows. Examples are PCI-AER, any APEI event notified by polling or one of the flavours of irq. I would expect Qemu to generate a HEST based on its abilities, i.e. if it supports any mechanism of notifying the guest about errors. Choosing the mechanism then depends on the type of error. Ideally the Qemu code for HEST/GHES/CPER generation code using some of the irqs and polling could be shared with x86, as these should be possible using common KVM APIs. ----------------------------------------------------------------------------------- He means we can use APEI on CPUs without RAS and may be share this code with x86, if Qemu can support any mechanism of notifying the guest about errors, it should be generate the table. Now we depend on the macro KVM_HAVE_MCE_INJECTION to decide whether Qemu can support notifying the guest. what do you think which we should be dependent on to generate the table? > >> if the old kvm does not support RAS, it does not have bad impact. only waste table memory. >> May be we can make it as device? if this device is enabled in the qemu >> boot parameters, then we will add this table? >> > > And you need to add a option to virt machine for (migration) > compatibility. On new virt machine it's on by default while off for old > ones. ok. > > Thanks, >