From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 01D4C2194233D for ; Fri, 7 Apr 2017 02:21:50 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E39893DBC1; Fri, 7 Apr 2017 09:21:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E39893DBC1 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E39893DBC1 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-118.phx2.redhat.com [10.3.116.118]) by smtp.corp.redhat.com (Postfix) with ESMTP id E1E6D18969; Fri, 7 Apr 2017 09:21:42 +0000 (UTC) To: gengdongjiu , Achin Gupta References: <76795e20-2f20-1e54-cfa5-7444f28b18ee@huawei.com> <20170321113428.GC15920@cbox> <58D17AF0.2010802@arm.com> <20170321193933.GB31111@cbox> <58DA3F68.6090901@arm.com> <20170328112328.GA31156@cbox> <20170328115413.GJ23682@e104320-lin> <58DA67BA.8070404@arm.com> <5b7352f4-4965-3ed5-3879-db871797be47@huawei.com> <20170329103658.GQ23682@e104320-lin> <2a427164-9b37-6711-3a56-906634ba7f12@redhat.com> <7c5c8ab7-8fcc-1c98-0bc1-cccb66c4c84d@huawei.com> <6ac1597a-2ed5-36b2-848d-5fd048b16d66@redhat.com> <55546a4b-c33b-37b9-dafe-15ce75bc1b62@huawei.com> Cc: ard.biesheuvel@linaro.org, edk2-devel@lists.01.org, qemu-devel@nongnu.org, zhaoshenglong@huawei.com, James Morse , Christoffer Dall , xiexiuqi@huawei.com, Marc Zyngier , catalin.marinas@arm.com, will.deacon@arm.com, christoffer.dall@linaro.org, rkrcmar@redhat.com, suzuki.poulose@arm.com, andre.przywara@arm.com, mark.rutland@arm.com, vladimir.murzin@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, wangxiongfeng2@huawei.com, wuquanming@huawei.com, huangshaoyu@huawei.com, Leif.Lindholm@linaro.com, nd@arm.com, Michael Tsirkin , Igor Mammedov From: Laszlo Ersek Message-ID: <09c64b28-5eb5-4efd-6cb8-035b69313a99@redhat.com> Date: Fri, 7 Apr 2017 11:21:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <55546a4b-c33b-37b9-dafe-15ce75bc1b62@huawei.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 07 Apr 2017 09:21:50 +0000 (UTC) Subject: Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 09:21:51 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 04/07/17 04:52, gengdongjiu wrote: > > On 2017/4/7 2:55, Laszlo Ersek wrote: >> I'm unsure if, by "not fixed", you are saying >> >> the number of CPER entries that fits in Error Status Data Block N is >> not *uniform* across 0 <= N <= 10 [1] >> >> or >> >> the number of CPER entries that fits in Error Status Data Block N is >> not *known* in advance, for all of 0 <= N <= 10 [2] >> >> Which one is your point? >> >> If [1], that's no problem; you can simply sum the individual error >> status data block sizes in advance, and allocate "etc/hardware_errors" >> accordingly, using the total size. >> >> (Allocating one shared fw_cfg blob for all status data blocks is more >> memory efficient, as each ALLOCATE command will allocate whole pages >> (rounded up from the actual blob size).) >> >> If your point is [2], then splitting the error status data blocks to >> separate fw_cfg blobs makes no difference: regardless of whether we try >> to place all the error status data blocks in a single fw_cfg blob, or in >> separate fw_cfg blobs, the individual data block cannot be resized at OS >> runtime, so there's no way to make it work. >> > My Point is [2]. The HEST(Hardware Error Source Table) table format is here: > https://wiki.linaro.org/LEG/Engineering/Kernel/RAS/APEITables#Hardware_Error_Source_Table_.28HEST.29 > > Now I understand your thought. But if you mean [2], then I am confused, with regard to firmware on physical hardware. Namely, even on physical machines, the firmware has to estimate, in advance, the area size that will be needed for CPERs, doesn't it? And once the firmware allocates that memory area, it cannot be resized at OS runtime. If there are more CPERs at runtime (due to hardware errors) than the firmware allocated room for, they must surely wrap around in the preallocated buffer (like in a ring buffer). Isn't that correct? On the diagrams that you linked above (great looking diagrams BTW!), I see CPER in two places (it is helpfully shaded red): - to the right of BERT; the CPER is part of a box that is captioned "firmware reserved memory" - to the right of HEST; again the CPER is part of a box that is captioned "firmware reserved memory" So, IMO, when QEMU has to guesstimate the room for CPERs in advance, that doesn't differ from the physical firmware case. In QEMU maybe you can let the user specify the area size on the command line, with a machine type property or similar. Thanks Laszlo