From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Richter Subject: Re: [PATCH V17 01/11] acpi: apei: read ack upon ghes record consumption Date: Fri, 30 Jun 2017 12:10:43 +0200 Message-ID: <20170630101043.GZ658@rric.localdomain> References: <1495225933-4410-1-git-send-email-tbaicar@codeaurora.org> <1495225933-4410-2-git-send-email-tbaicar@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1495225933-4410-2-git-send-email-tbaicar@codeaurora.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu To: Tyler Baicar Cc: linux-efi@vger.kernel.org, kvm@vger.kernel.org, matt@codeblueprint.co.uk, catalin.marinas@arm.com, 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, rafael@kernel.org, zjzhang@codeaurora.org, linux@armlinux.org.uk, gengdongjiu@huawei.com, linux-acpi@vger.kernel.org, eun.taik.lee@samsung.com, shijie.huang@arm.com, labbott@redhat.com, lenb@kernel.org, harba@codeaurora.org, john.garry@huawei.com, marc.zyngier@arm.com, punit.agrawal@arm.com, rostedt@goodmis.org, nkaje@codeaurora.org, bp@alien8.de, sandeepa.s.prabhu@gmail.com, linux-arm-kernel@lists.infradead.org, tony.luck@intel.com, 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.comsh List-Id: linux-acpi@vger.kernel.org Tyler, On 19.05.17 14:32:03, Tyler Baicar wrote: > A RAS (Reliability, Availability, Serviceability) controller > may be a separate processor running in parallel with OS > execution, and may generate error records for consumption by > the OS. If the RAS controller produces multiple error records, > then they may be overwritten before the OS has consumed them. > > The Generic Hardware Error Source (GHES) v2 structure > introduces the capability for the OS to acknowledge the > consumption of the error record generated by the RAS > controller. A RAS controller supporting GHESv2 shall wait for > the acknowledgment before writing a new error record, thus > eliminating the race condition. > > Add support for parsing of GHESv2 sub-tables as well. > > Signed-off-by: Tyler Baicar > CC: Jonathan (Zhixiong) Zhang > Reviewed-by: James Morse > --- > drivers/acpi/apei/ghes.c | 59 +++++++++++++++++++++++++++++++++++++++++++++--- > drivers/acpi/apei/hest.c | 7 ++++-- > include/acpi/ghes.h | 5 +++- > 3 files changed, 65 insertions(+), 6 deletions(-) > static int ghes_proc(struct ghes *ghes) > { > int rc; > @@ -661,6 +704,16 @@ static int ghes_proc(struct ghes *ghes) > ghes_estatus_cache_add(ghes->generic, ghes->estatus); > } > ghes_do_proc(ghes, ghes->estatus); > + > + /* > + * GHESv2 type HEST entries introduce support for error acknowledgment, > + * so only acknowledge the error if this support is present. > + */ > + if (is_hest_type_generic_v2(ghes)) { > + rc = ghes_ack_error(ghes->generic_v2); > + if (rc) > + return rc; > + } > out: > ghes_clear_estatus(ghes); > return rc; was there any specific reason why the ack is sent before clearing the block status? Spec says the ack should be sent at last. Also, the block is never cleared if ghes_ack_error() returns an error. IMO we should fall through and clear the block status (this will change anyway if the bloc status is cleared first). -Robert From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752956AbdF3KLR (ORCPT ); Fri, 30 Jun 2017 06:11:17 -0400 Received: from mail-sn1nam02on0078.outbound.protection.outlook.com ([104.47.36.78]:17783 "EHLO NAM02-SN1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751933AbdF3KLL (ORCPT ); Fri, 30 Jun 2017 06:11:11 -0400 Authentication-Results: codeaurora.org; dkim=none (message not signed) header.d=none;codeaurora.org; dmarc=none action=none header.from=cavium.com; Date: Fri, 30 Jun 2017 12:10:43 +0200 From: Robert Richter To: Tyler Baicar Cc: christoffer.dall@linaro.org, marc.zyngier@arm.com, pbonzini@redhat.com, rkrcmar@redhat.com, linux@armlinux.org.uk, catalin.marinas@arm.com, will.deacon@arm.com, rjw@rjwysocki.net, lenb@kernel.org, matt@codeblueprint.co.uk, robert.moore@intel.com, lv.zheng@intel.com, nkaje@codeaurora.org, zjzhang@codeaurora.org, mark.rutland@arm.com, james.morse@arm.com, akpm@linux-foundation.org, eun.taik.lee@samsung.com, sandeepa.s.prabhu@gmail.com, labbott@redhat.com, shijie.huang@arm.com, rruigrok@codeaurora.org, paul.gortmaker@windriver.com, tn@semihalf.com, fu.wei@linaro.org, rostedt@goodmis.org, bristot@redhat.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-efi@vger.kernel.org, Suzuki.Poulose@arm.com, punit.agrawal@arm.com, astone@redhat.com, harba@codeaurora.org, hanjun.guo@linaro.org, john.garry@huawei.com, shiju.jose@huawei.com, joe@perches.com, bp@alien8.de, rafael@kernel.org, tony.luck@intel.com, gengdongjiu@huawei.com, xiexiuqi@huawei.com Subject: Re: [PATCH V17 01/11] acpi: apei: read ack upon ghes record consumption Message-ID: <20170630101043.GZ658@rric.localdomain> References: <1495225933-4410-1-git-send-email-tbaicar@codeaurora.org> <1495225933-4410-2-git-send-email-tbaicar@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1495225933-4410-2-git-send-email-tbaicar@codeaurora.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [77.180.217.185] X-ClientProxiedBy: VI1PR0802CA0040.eurprd08.prod.outlook.com (10.172.253.26) To CY1PR07MB2348.namprd07.prod.outlook.com (10.166.194.147) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b8b98af0-0996-496d-5248-08d4bfa0502c X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:CY1PR07MB2348; X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2348;3:zYjCTgl2hkGq1X/KO1mgRBb+FGCb6tCnMSsPmbEeSK2K9XwiRDbISnpZp7Z4g1yNBcFqOareFocKcyOW/bF0eH27fLKR5wdRYdNwrcdjF8iMzJiiR+Fhhg0D8R08nDbx0tsoPkroYw+HlEHXyLomaKvAJaAH4x4IdwaH4VMSKxYsuBLq2kT+A1IQAkuW4fdy/5V24uSTgzYJuBynHscTeyW8BxRq5rwudgBEKKpFI6qIFoyhH7HUd29EK34dDtooMSWpjK7+Tt2mmFiAWhuioOoGjAXjBbQxUlttfeFrQsXc3ViXruosXFlFiR8JfFhfIhFJlYfa9gA3roaRZD6Oc4m86gqApTqoUIP0uhIMpJOWjzCyvYmPk5Pw4boJfbT6agC+DlugNHJehUtiDgUyqxRVF/6i1ljxVBCdcMLlUzCujQxTW74ucRRCL47zIQ/j45PkKArirFGAJPTFCknZhqfvGy1e95y0bub9nooCiJt5jrmVxhOEN5zL/Du96EmRQ5oedCjjr31ocBXbkK73Xr/A6nDGVV1zJvNeSQw4b7RBSmbelzBoiqO0O84gv5EowdY7DoC4CvbSi/rNbU2ujUrgjheySJF45lJY0QVt+dQAoXQ04Pgvklb+THT1F2cq1yuUMj2aLxpUGbK/XK0JW4Dy62WrL6x4ausoXSzjg6paUaWWZTiQ9G9Pwh2ZFiI5ryTLmr6QAVIqqUOehOyRDxZk34XxR/z8CT0MeFBDHEw= X-MS-TrafficTypeDiagnostic: CY1PR07MB2348: X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2348;25:tFctLBEH4A0h1Jn0natkS7gKS1kSbKSLOKxH8P45i3NEX3WqZ7x4+voB1o5e2WZUV+sVFYXjCmnMHobGYCKAHbj2dQIK4s5yglXOe1km31ooutefusUwSUd017ep/LE/h6jp/95m76F/EIiPSAHhRHnRdBGT6L4aa7gY7l6fnFnZUg+B4bXDdnPv/0wVOF+QZdf7opNlfTaVsst0RK2aIler4wXXcNPrcVgs78S3J5xPjAOMP/OvilxLEAXTRR9jVVefqpRJE0bDxlvM4O/izIJQZpF32p3yWOpozEHyyjd3QDJpEYp8Hl+oYyg8akS4fCmgs7o+RN333tlWXksdZMub4I3bRgSZiQmnB5/RQyF74y2kQpAm1u/KaBYU7mG9Ruqp/9NwZQVB4Ujwzp0fdl44OgUo+e+HHckCGtAeLr1Lmbkyn1ONmwiFZ8WPT0hISCkr3plvIr9YYHqywnJqUN7ltWgbbAAgcii8p+LaJsj8eHgWgJtXnKZf8Z48nHpTYKPbJCuytfUBshZ6Gtrj/OiWk2dnq6Y+tpOEisJ+oGtbxHQCk8nxJMfYLC7AAZItapeUXCCHIq2SBHZ/cH+z9o6kk782FqFWM0zfzMPukEDlv4H53pE33DOQj3FUR8SXiLdgmTdXxEo9vnQknKv1gY93ABaFs+DcGjegHgoZKeXz+5Ih0RftqfEVdVvhlnswqiiT/bgP7JlJjLimC8gcsIR3qAcACkDrmoeOXkQlgv9VfZfpqvoFjy7B/Gg1mhEehEZjUzWb2RQtTV5m1kc3dYaWuJmq4KaUkqNHblbL8TTOFmTD4Lo+3Jkq/DVyULS0OHGdoR6aNdFyu4Upk8Ds6iXM3nQIaSZfjFofG/lPQoi5lbKpIabObFUGlQLBas72arUHR/n52IuLC3XR0fRkk9ejsSldgMMzMl0YTwjqZhc= X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2348;31:NWuT7xROLw3J+NAS3eMU1Z7tfjoFtKZOmiiyVkNkgZT0fT3iKqcqoVMe16l4uaommKTsOerO53V36uV8PkyNd/ni8MS2B6dvMSlg4rcxfRTw4pjwSrIXWdMBW1522S8WkwnTuVwX02vUGHfTJx4ZrK0nFmzmkgWqa0X9qbbAaCniYItOx/9HtnR8uzPLIM721wPl8TSkGfrqxOsSmerBIfyAvUo0JMFkAoBbaQAoGAq65u4EUxzp8yEyqIU2AiRtOTWHs/fsBu51nlVtJAb7KnpG3eErh8tQHYzAslAlj9ZLLNLKHcuyqgjDLcT6iTJQw7dNS1hfur32CzcKlxpSUx2v6lpQ9eClbTai4GM/sdZqvaoE4AtPPfuNExg7tVs/laaG2fTfJRccpcE/OvUp5g9pDd2T/8amKMxtXBO1BUvgeHjWfzQXIx8rfA+AMLGleK+yLf5mjg7buHk9pvDKWRFpghw7Jhlk0IUzRsOMHFJn9h7bxZunxusuNRIPIOdxvwFdnSTq/wqTzkK4/P9ZzCjRV1C636t2AM391tiRJYgT+Xvm9965W2RTfjIVbsJkZ72YKBdPe1NP54h0Er05O7v0pJK9WAfq7zB14zHBk/GilkflqR9qFCcFMOg6eMPuxIjqLNqqT2+iGdg9dmC0SXr1PftNBzOnM89Qz2Q4tqvC7QW8f9xri1nQ203XHIYjVm6BQSzlwe7b8vCYObez5w== X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2348;20:ugjYuby7aCenxBWjHG7gVSNPjv3xzwV6X+ov3wgxNF1aBz9XUfrVN57MwSpeJ8Xpveg/cUAqh28gPdxvDJ95PozZUMoOBXOmlXuy2cZidhoSjVP0wu4bHIkQ3sx5OnPxrfhKl+K44NeNBDAZGTLfN8m5HKAOoH/U/EnhlioEQcNew2F/LrfsGkzJJ85QfJ0ibU2MIoku+7/kF2f7+dwzHwbK2q3sjObMhqa0mzyOiYXaQhYx39pYvwOqpr+X2WatjqSgd44rP0h2NIcuI8mzErLP5+czkobJTEgZmi3UVoFmQa1hRgxTXAhz29Nrh4iqo1tke3QSUmIsZCF3xvP6ow9h10Aj+Omo2IwUYa5xEs+4u4UAvtPNNcdkVdvSjKm9LRAFNgVJssilYPNLb/wnib3GqrHMoT76gn1NrBuhbOQ/LNR8ICs26iXYjk6DjZmSeFxEtfnEMl+jXT7j/kxkovD3wqDOFe29TpyVm/3yqUsyfpS5cpJzpMpRo1zyZLz6 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(180628864354917)(133145235818549)(236129657087228)(148574349560750); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:CY1PR07MB2348;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:CY1PR07MB2348; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;CY1PR07MB2348;4:3+Tbmxxo416O8JgDAEr0TGva0GoaQoT0oXnx8kLobx?= =?us-ascii?Q?hA7QQf2VxJq1KBVePmcfqeSjn0A2GZ/kTsm0COZjKGjfggjPVHcoy35i2qDA?= =?us-ascii?Q?r8AJVl7+Z2i6+jRg9r6hEb+cjPHOoJjgFug03Dvy5l3nllL0/fEt7z1T/bU0?= =?us-ascii?Q?fQXbBEqB/gDBMNytuwoB9Rw3WtBCCscLNf1OZgjV0B16GASCyDzi97BL3zy6?= =?us-ascii?Q?7tM64ev1iYC7ssz9P3keY/D5dgOYK6q4qAhzjbXcjmcEEX7fLKY0yH/UVILc?= =?us-ascii?Q?JxCXVK7rXPhgvxWBKvKuqNEqWzIJ8ctQgO6A0dtBrFoEG8MRkHk3tHmB/DcH?= =?us-ascii?Q?tkeT2auqTMDWbul0FVJ485VV5TET3n6eQIFGDt3Z6TAf1x6EvFzOyr4ohYmV?= =?us-ascii?Q?6UYqPGviggjFzHae+fw9/HAukh56FYlUUf0dzseP/HFhZDU9524nDuoQuQNH?= =?us-ascii?Q?qVHwgmA635G9y/B33saAwRMYLOomYZVLG0s+0bYKt5aZTKLzUn2IEyxFPc9Q?= =?us-ascii?Q?RO5BUEubCiXIzg7SSzgLTN1JnNb+91ohIsnAvWYZ4GuswQzuL1xdXe7/o1y0?= =?us-ascii?Q?9ukF95fb/3fyprehu96r4uil607iQzJodrE7Dp6QAKUquTVGXcVJhhG174mi?= =?us-ascii?Q?7UBZerkG/Pli0+Ge+Iejv0cpGW8r/kIY/HQfnvPixygKr5t2eZdYICuVgeKR?= =?us-ascii?Q?IozsYeIMRuU0ZsbDbzEZniFnPTtkwcVapc1T5LMQ3iyNRZdmQUcH2fATO6Qy?= =?us-ascii?Q?UVu1e1BFyqShClpl6Ph9E4TXMU1BCZu517oZCrPt2REYTIMrd1Fv0HbzSEr9?= =?us-ascii?Q?jrpx6KSeTmL3cODGK17ti+agbe0x+XHEbCnx/lcZAHEq/beJLONWKimAl9cQ?= =?us-ascii?Q?noJQth1Gx5LC40BHeVjsSZBneElGg76hOtDHWz96iwTF2iQOxa7x6sF/ea5M?= =?us-ascii?Q?2bSsSMFY1XnrLF0v2/V60MXwpm53xCP405rfGAy+74MZJm/hGB88RmgSn3/3?= =?us-ascii?Q?km12sZ5arWVqL8XRHG4ZWjTb5FyFWaa5ycTRaTVetz0F2nrPlgC34uuH3utZ?= =?us-ascii?Q?qzpBnrOOQQ+GEiFszoOeFjUYcbKE1fqtMd57b2+nQIQlbjIWwShXv1ql7G33?= =?us-ascii?Q?MhR7alVYKxp8wKGMnDGbjdHcrMaU010KTxYjo5emNWVhhIMwaR71UNu6Dxws?= =?us-ascii?Q?uyASE+l2zTf9RQHEBdvDyV1TWYpipXJj1lnjcaD5pvidcgADfXrYfWc/M9Xe?= =?us-ascii?Q?NPZeOQfkOcy/V3+coTApMA+rrT8Mo/VN6lQoYK7UZE+2aHQU3VhdcqnCp4LQ?= =?us-ascii?Q?=3D=3D?= X-Forefront-PRVS: 0354B4BED2 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(39410400002)(39400400002)(39450400003)(39850400002)(24454002)(53546010)(189998001)(6506006)(8676002)(4326008)(81166006)(83506001)(6116002)(33656002)(5660300001)(2906002)(7406005)(23726003)(3846002)(50466002)(1076002)(4001350100001)(6246003)(7736002)(25786009)(42186005)(54356999)(50986999)(76176999)(305945005)(6916009)(72206003)(2950100002)(53936002)(55016002)(6666003)(478600001)(86362001)(9686003)(47776003)(66066001)(110136004)(38730400002)(18370500001);DIR:OUT;SFP:1101;SCL:1;SRVR:CY1PR07MB2348;H:rric.localdomain;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;CY1PR07MB2348;23:Hq/uAyxhxOZe/XhbfiEGBmmaDC1NL0pl287s1GH7g?= =?us-ascii?Q?/0faMS/uovGCdbLHtfATm11nf5pHvkQggku6t5qopCdtNO92mcrVDP9DmirM?= =?us-ascii?Q?0LgslYQcGnYpXuxBFNccoGASpJMNAnzDfOQRBlUr+jifqkPcdsttwbI1s1Mu?= =?us-ascii?Q?gZb4ambxsWtNtLUhVyZeSY9Ai8g8/sNAkD4oO+1TLfC0AtPVpIhC1GPA2flC?= =?us-ascii?Q?0d4KImJmJvgKG21e+0sZ+XrYb27HzoRsNxHWcOHFpbTGxaOtAt7vVZLwUcc8?= =?us-ascii?Q?IB1fQvqR1xzAjHYpGi9XxG8pUNrZ6BnVbGEZs35ye7932BNACBKgtrjLKdrt?= =?us-ascii?Q?Ppp5D8SJzxqDXo/3HpiTZZXuk21QvNakHy2ctXcbr0RaRHxjeOKtoECearmG?= =?us-ascii?Q?u835+CymQzMzgFBZbzfN4x6H6uFW1IarlKIzWBC0tyCuUjn0EjRLJ1yeC4KI?= =?us-ascii?Q?wxKIg37tMYO0JjQqh62RXz56x2ZxS4PJav2NtQu4qN7ABrIpDE9caPFtH7H+?= =?us-ascii?Q?CiGRk4084aMMqDO2A8meeH6OWTNX9UOeajGgPUol4R5sptJLVAQjD4F0Zzm3?= =?us-ascii?Q?KXlqN1Sy4c2MzdNFyXcQTbFRf7N1gnH/Ib755h9X25preTrJgWhB5uMBS9/r?= =?us-ascii?Q?XxIat9wx5yGHOZHgD6xIE+oaQrpwvlpE2S3jbXI3/YAeWHocH3j4rKBPDVnp?= =?us-ascii?Q?hgm7ACBJF8Ox2hJKfype7KUWK4W89/cCeDuIxo/nWhHSl9E0afrApbTFNCQQ?= =?us-ascii?Q?Nu65X1m5JRebceTzXvMnd9KG5+FeDDpwYjpR+zTZr7dhPniiLZKDO1zT3d6E?= =?us-ascii?Q?J9UOVNWXGy9U/sUw8KoVz3KWBt+cqrgXAQka7j0U7Ut6OmyDZSqE30zX7agP?= =?us-ascii?Q?QB7lac2XKbO4WFap9pLCWUaLxzXriIqY95ikj32MOiwZYVW2KUVcQOTf2Bph?= =?us-ascii?Q?n40sA9IJF2uJjzlmHui7UfLKRWB/pdEMf8iDBOPSEZTIuv0ktJTttucYZoJD?= =?us-ascii?Q?R2qzmoiuP6894MBHxbZvA4fLwMxE8+0mZIutFxhcQ1a5eFxObsL18pwwLYdM?= =?us-ascii?Q?2VOeQ7FWPU7wVU8bO8kSEcVfRZGUPSwCznRlqp/4QsZw5syxXTgXrutUE/eL?= =?us-ascii?Q?3SwB+XUq83tkHabFM6JejtkQstNQryK?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;CY1PR07MB2348;6:8DEqcqsyj5gMNnhUPBo0vi7ZNqDLyS2WYB6OhpDHhe?= =?us-ascii?Q?giq2jRsr+ymbtFGVNPgw4Xuj2WQ295Rnv645SuTkgbAAOzNtHCW/mliZratJ?= =?us-ascii?Q?PmXJN+eTdcqMhOhtTl88GxZSPCh+Pbm31/HCG3zdnMWrhAeLcAzl/yOoUGFV?= =?us-ascii?Q?s2cChK0E0wq3UfdTAALP0LOEJTwpICDUPqAkHL1eS9SpAZUlR0lkM6RE3xr3?= =?us-ascii?Q?oOsrCRIRdeU0aLt23saMgRkQZDAwpOG6/zRzlRtBbmO8QyDPGqvjp+vLtBJ3?= =?us-ascii?Q?TnVWopqceyGP3YX98GfGSI2zesyL7ArwJRIij+1LBF8ZJPCuGOfvfZH6gay9?= =?us-ascii?Q?8z23NDhLRu+Hi5kpn0L+XmosTfm1Rpfy9VW9iRvaDp5/ZDXMgAiR6O0BodGa?= =?us-ascii?Q?qZwJPM8DNMEwlajSiQu0FEwiUjmtKB/8S591b0POD9eezX3SC77p3jZby19b?= =?us-ascii?Q?3tpl3LizKPveHtphA8o9LYnTP4yAnALMlJ9+3d8IuXR5exCsAlw/ZsxbyuuJ?= =?us-ascii?Q?EqMTWrVSSCOwUv8IV0CERSKr0WnjXKi/xn92t6OJ0SaJCFErKekK2rt1HT6I?= =?us-ascii?Q?JymytEDc74SWKVMEyHJ7QK/yNWomohGzEqb9NEHfQ6+hHRUDXW5qY50Lr58y?= =?us-ascii?Q?Zgm9JuEjajUUmzHIZcLUFauXI9wmdMyZSenwi5F28bG3imyYig1WvuEdzUXs?= =?us-ascii?Q?6u2ld5+Hv7QJlejya7ZGEq/kchV4w4FAaNSAEEhBHltotpO9QOggG7rvtzjp?= =?us-ascii?Q?G8Dc/N491FoCN0ZVRBXOfvvHBKpALgKngAoksG5fnIW/tC4tqgCEcZ77jtkP?= =?us-ascii?Q?b55fkL2mSpgTbo1I4HVvjhwc6bOODvlzPK0QZ8Lvn7dQ2Jgxj321nJOIYIGA?= =?us-ascii?Q?TQGMXc6izZG4ZpcywyhTIQL6Cc2H6s53Q8MpaiM2JGLZDA4Qsjua0GQfQW8h?= =?us-ascii?Q?cGcp9JK7fr6+J+9me3x3SQPPORpMBu93glXz0kcK1EjHQvBhfydIdD87rQX7?= =?us-ascii?Q?s=3D?= X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2348;5:LQZxYuUvzR1abiKe8s8jX+aEvJgdNUQYIOH9V+McotZhlf6A0zFI2+Ff44reJazlopqcYf79OO/KbH9uzHX68GJ5IjHOhVl5POM6LkwQr+wiPJxE7DEHR9UqXC9gfUUne2KSnC0SR0CbOPCXqmtzhjTUlSTu/7bFpIoo2YzELuCG+Sq8/hamU6wqJOw5H2VsPmSBHjsEltP9L41CW8eRhnCxqnBSGRIWJBYVudr1qR/9Kb4+A0jOUsYZHf7W2xHgVI7Bx5NvyvDNwpsLSg8gCTWUt3JOGdQrvr1wCkuultyqfXTNeRCB9Hhf9NDkIc4zjJfuTj6lGA+SOiKm2Dd+tpCBfd7bLC4WVcRzr1KV6U63JIfmrruDs6U6eRlimWOZVbCuaSAF1W1+yESWxMRosIJYfLY7cKIz+nQHS8RE8iC0ERpvLa0J7Fjxm9EZN72rcTFU3hUCT9MXuIMP1he6EuRJ35jIMvdZL/mhP1hB/qBkZXwg0srTQ4t6Rjq1sIep;24:e9U4RtZ8YBAcdEp+HvZvF6H851P0uZvyTn5fjrslfeT27pKiLzgSinYBE/xWjYE2t/2w7HkEoHhIkEp0pkppOhAvG5Cs1g9ED3pzwv0VDzA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2348;7:azIgc9Jsm62LdEgmTVW7OEm0fVnKMef/RBOOeRhVuhc8wXq02Igq8uQRlPF+on2tn9sU4sEFTB9JsnpSyN/Px+9U5USE+Gsc5UowAL9R7Ne5U4twFxRJYU8jjLa6+m2k0JUhIXJZVhGoGFTYUO5vF0rQU9uUUuSczFg0YXnx+Jfhw4I1iydb9yunzMglrTLX1asTmOdDvHU9GR9wxOEdhtdqa9eip3LKb8ZAe+Q9Wl0wLnLuifZ6e9zKc56OrTzQ2tmf1gQyWYErv/eA9A3WhtcWiMalSZXxPypaL5nvZhK/nLJo7eIVRs4CXC9C8Dw1yTYRmp7VF7CMRuMkHDUSc1dw2gDXp9xpYmERPPYqXaIMTLfQ42cuUP8f4OpXsFDyawG2eTQCMGq2zkleGCwDmhJYVIcBYFk18B+DaYWiiXGWdLmzrb3fbhV7sOUFbM3qy+v+sYLrdjGNupf2a3PzXsDXqiY/cgtIw2lwgtvhwXMeynyHEz5sF2Dk5VNiOyFOgFShhHNmZtLZ63W1R+R2vuEFZh4Qrw+iDo2xTzDREQcOFrMNZcd7udXAGRH9wpWvVT1yfun90//C0KHkzbk3VyDXTjTtM6UHfanfhicICnBlg33USE9yKDCp4o+WvwX//zDeIN3vrcoPJOq68LvIy37KgnUWZcN9VmpjHzofVN81LgrRsIxhnA9Zruwv51eGyfvIWtArjO+6lkRnAOT5qrZRDpBdOBQ8qPXjxntig/YRTOXuLN0mZiyytElbCvndMgxGNkm97CHpycgulWjtRLZP6G1JgfhV0cUUDLxKbPM= X-OriginatorOrg: cavium.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jun 2017 10:10:53.2770 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR07MB2348 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tyler, On 19.05.17 14:32:03, Tyler Baicar wrote: > A RAS (Reliability, Availability, Serviceability) controller > may be a separate processor running in parallel with OS > execution, and may generate error records for consumption by > the OS. If the RAS controller produces multiple error records, > then they may be overwritten before the OS has consumed them. > > The Generic Hardware Error Source (GHES) v2 structure > introduces the capability for the OS to acknowledge the > consumption of the error record generated by the RAS > controller. A RAS controller supporting GHESv2 shall wait for > the acknowledgment before writing a new error record, thus > eliminating the race condition. > > Add support for parsing of GHESv2 sub-tables as well. > > Signed-off-by: Tyler Baicar > CC: Jonathan (Zhixiong) Zhang > Reviewed-by: James Morse > --- > drivers/acpi/apei/ghes.c | 59 +++++++++++++++++++++++++++++++++++++++++++++--- > drivers/acpi/apei/hest.c | 7 ++++-- > include/acpi/ghes.h | 5 +++- > 3 files changed, 65 insertions(+), 6 deletions(-) > static int ghes_proc(struct ghes *ghes) > { > int rc; > @@ -661,6 +704,16 @@ static int ghes_proc(struct ghes *ghes) > ghes_estatus_cache_add(ghes->generic, ghes->estatus); > } > ghes_do_proc(ghes, ghes->estatus); > + > + /* > + * GHESv2 type HEST entries introduce support for error acknowledgment, > + * so only acknowledge the error if this support is present. > + */ > + if (is_hest_type_generic_v2(ghes)) { > + rc = ghes_ack_error(ghes->generic_v2); > + if (rc) > + return rc; > + } > out: > ghes_clear_estatus(ghes); > return rc; was there any specific reason why the ack is sent before clearing the block status? Spec says the ack should be sent at last. Also, the block is never cleared if ghes_ack_error() returns an error. IMO we should fall through and clear the block status (this will change anyway if the bloc status is cleared first). -Robert From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Richter Subject: Re: [PATCH V17 01/11] acpi: apei: read ack upon ghes record consumption Date: Fri, 30 Jun 2017 12:10:43 +0200 Message-ID: <20170630101043.GZ658@rric.localdomain> References: <1495225933-4410-1-git-send-email-tbaicar@codeaurora.org> <1495225933-4410-2-git-send-email-tbaicar@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: linux-efi@vger.kernel.org, kvm@vger.kernel.org, matt@codeblueprint.co.uk, catalin.marinas@arm.com, 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, rafael@kernel.org, zjzhang@codeaurora.org, linux@armlinux.org.uk, gengdongjiu@huawei.com, linux-acpi@vger.kernel.org, eun.taik.lee@samsung.com, shijie.huang@arm.com, labbott@redhat.com, lenb@kernel.org, harba@codeaurora.org, john.garry@huawei.com, marc.zyngier@arm.com, punit.agrawal@arm.com, rostedt@goodmis.org, nkaje@codeaurora.org, bp@alien8.de, sandeepa.s.prabhu@gmail.com, linux-arm-kernel@lists.infradead.org, tony.luck@intel.com, 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, sh To: Tyler Baicar Return-path: Content-Disposition: inline In-Reply-To: <1495225933-4410-2-git-send-email-tbaicar@codeaurora.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu List-Id: kvm.vger.kernel.org Tyler, On 19.05.17 14:32:03, Tyler Baicar wrote: > A RAS (Reliability, Availability, Serviceability) controller > may be a separate processor running in parallel with OS > execution, and may generate error records for consumption by > the OS. If the RAS controller produces multiple error records, > then they may be overwritten before the OS has consumed them. > > The Generic Hardware Error Source (GHES) v2 structure > introduces the capability for the OS to acknowledge the > consumption of the error record generated by the RAS > controller. A RAS controller supporting GHESv2 shall wait for > the acknowledgment before writing a new error record, thus > eliminating the race condition. > > Add support for parsing of GHESv2 sub-tables as well. > > Signed-off-by: Tyler Baicar > CC: Jonathan (Zhixiong) Zhang > Reviewed-by: James Morse > --- > drivers/acpi/apei/ghes.c | 59 +++++++++++++++++++++++++++++++++++++++++++++--- > drivers/acpi/apei/hest.c | 7 ++++-- > include/acpi/ghes.h | 5 +++- > 3 files changed, 65 insertions(+), 6 deletions(-) > static int ghes_proc(struct ghes *ghes) > { > int rc; > @@ -661,6 +704,16 @@ static int ghes_proc(struct ghes *ghes) > ghes_estatus_cache_add(ghes->generic, ghes->estatus); > } > ghes_do_proc(ghes, ghes->estatus); > + > + /* > + * GHESv2 type HEST entries introduce support for error acknowledgment, > + * so only acknowledge the error if this support is present. > + */ > + if (is_hest_type_generic_v2(ghes)) { > + rc = ghes_ack_error(ghes->generic_v2); > + if (rc) > + return rc; > + } > out: > ghes_clear_estatus(ghes); > return rc; was there any specific reason why the ack is sent before clearing the block status? Spec says the ack should be sent at last. Also, the block is never cleared if ghes_ack_error() returns an error. IMO we should fall through and clear the block status (this will change anyway if the bloc status is cleared first). -Robert From mboxrd@z Thu Jan 1 00:00:00 1970 From: robert.richter@cavium.com (Robert Richter) Date: Fri, 30 Jun 2017 12:10:43 +0200 Subject: [PATCH V17 01/11] acpi: apei: read ack upon ghes record consumption In-Reply-To: <1495225933-4410-2-git-send-email-tbaicar@codeaurora.org> References: <1495225933-4410-1-git-send-email-tbaicar@codeaurora.org> <1495225933-4410-2-git-send-email-tbaicar@codeaurora.org> Message-ID: <20170630101043.GZ658@rric.localdomain> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Tyler, On 19.05.17 14:32:03, Tyler Baicar wrote: > A RAS (Reliability, Availability, Serviceability) controller > may be a separate processor running in parallel with OS > execution, and may generate error records for consumption by > the OS. If the RAS controller produces multiple error records, > then they may be overwritten before the OS has consumed them. > > The Generic Hardware Error Source (GHES) v2 structure > introduces the capability for the OS to acknowledge the > consumption of the error record generated by the RAS > controller. A RAS controller supporting GHESv2 shall wait for > the acknowledgment before writing a new error record, thus > eliminating the race condition. > > Add support for parsing of GHESv2 sub-tables as well. > > Signed-off-by: Tyler Baicar > CC: Jonathan (Zhixiong) Zhang > Reviewed-by: James Morse > --- > drivers/acpi/apei/ghes.c | 59 +++++++++++++++++++++++++++++++++++++++++++++--- > drivers/acpi/apei/hest.c | 7 ++++-- > include/acpi/ghes.h | 5 +++- > 3 files changed, 65 insertions(+), 6 deletions(-) > static int ghes_proc(struct ghes *ghes) > { > int rc; > @@ -661,6 +704,16 @@ static int ghes_proc(struct ghes *ghes) > ghes_estatus_cache_add(ghes->generic, ghes->estatus); > } > ghes_do_proc(ghes, ghes->estatus); > + > + /* > + * GHESv2 type HEST entries introduce support for error acknowledgment, > + * so only acknowledge the error if this support is present. > + */ > + if (is_hest_type_generic_v2(ghes)) { > + rc = ghes_ack_error(ghes->generic_v2); > + if (rc) > + return rc; > + } > out: > ghes_clear_estatus(ghes); > return rc; was there any specific reason why the ack is sent before clearing the block status? Spec says the ack should be sent at last. Also, the block is never cleared if ghes_ack_error() returns an error. IMO we should fall through and clear the block status (this will change anyway if the bloc status is cleared first). -Robert