From mboxrd@z Thu Jan 1 00:00:00 1970 From: Borislav Petkov Subject: Re: [PATCH v7 10/25] ACPI / APEI: Tell firmware the estatus queue consumed the records Date: Fri, 11 Jan 2019 18:45:32 +0100 Message-ID: <20190111174532.GI4729@zn.tnic> References: <20181203180613.228133-1-james.morse@arm.com> <20181203180613.228133-11-james.morse@arm.com> <20181211183634.GO27375@zn.tnic> <56cfa16b-ece4-76e0-3799-58201f8a4ff1@arm.com> <20190111120322.GD4729@zn.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Tyler Baicar Cc: Rafael Wysocki , Tony Luck , Fan Wu , linux-mm@kvack.org, Marc Zyngier , Catalin Marinas , Xie XiuQi , Will Deacon , Christoffer Dall , Dongjiu Geng , Linux ACPI , James Morse , Naoya Horiguchi , kvmarm@lists.cs.columbia.edu, arm-mail-list , Len Brown List-Id: kvmarm@lists.cs.columbia.edu On Fri, Jan 11, 2019 at 10:32:23AM -0500, Tyler Baicar wrote: > The kernel would have no way of knowing what to do here. What do you mean, there's no way of knowing what to do? It needs to clear registers so that the next error can get reported properly. Or of the status read failed and it doesn't need to do anything, then it shouldn't. Whatever it is, the kernel either needs to do something in the error case to clean up, or nothing if the firmware doesn't need anything done in the error case; *or* ack the error in the success case. This should all be written down somewhere in that GHES v2 spec/doc/writeup whatever, explaining what the OS is supposed to do to signal the error has been read by the OS. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A540C43387 for ; Fri, 11 Jan 2019 17:45:50 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 12CA020874 for ; Fri, 11 Jan 2019 17:45:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="YLn7tKNX"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=alien8.de header.i=@alien8.de header.b="ePBKL0gz" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 12CA020874 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=alien8.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=OMtsx/fko0qoDEYuFBsD7+hkjX0EVR9it5EAj0SD6L8=; b=YLn7tKNX127m7O cMSoA2yIqwcC9MLwFywr6ItTNLj9i9HOR1MyPfMGQEDrug/oxaJNC2rEqIxaStIX4YlG9sAKgSPiC /0EKnvwFGi5HyfCgF1wBhyRx1lXMeOQUd8kENwk3eW9uR7I4j4p1DDzry9sDpc0MMpPLa/Sj/5Jtg gZ+4kqVwIKShmNx9HOxZB59G7qaEgITDQn4ppRhG9MoqNaJZfSEhJAl+5cD7ZAyNypiMFlHfu2v25 u7kE22cWu8689F2UzFUl7IRYp5lJsGfik27B/3RI4pzt4wOAWK5FkK1Cnn2dLAlTKcykkw+p7k2Bw 3m1ChAIM/2EhfVKQpnCg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gi0sH-0006X8-78; Fri, 11 Jan 2019 17:45:41 +0000 Received: from mail.skyhub.de ([2a01:4f8:190:11c2::b:1457]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gi0sD-0006Wf-Bp for linux-arm-kernel@lists.infradead.org; Fri, 11 Jan 2019 17:45:38 +0000 Received: from zn.tnic (p200300EC2BCAC5003956DFF8679C923C.dip0.t-ipconnect.de [IPv6:2003:ec:2bca:c500:3956:dff8:679c:923c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 67C371EC0432; Fri, 11 Jan 2019 18:45:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1547228735; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=C6meGvLj7DPHaw89eAz4zx+tq65KJG8Kh2yHjsBMUUk=; b=ePBKL0gzEqNWczWz8s1xWOrIQp/J9lVBc1OrpDcwewQMBXdWm5pyGC2fBhhHRN4GPssu98 u4RGqjV2eNkMpLYTI1jjxgabZGGWXhsRHGBE+qHb8ZlIpElJC4x+8tWsBclSPn8PY3OMCh TwxpQDfPAFNA8c+O5RRMCdP46tcva8I= Date: Fri, 11 Jan 2019 18:45:32 +0100 From: Borislav Petkov To: Tyler Baicar Subject: Re: [PATCH v7 10/25] ACPI / APEI: Tell firmware the estatus queue consumed the records Message-ID: <20190111174532.GI4729@zn.tnic> References: <20181203180613.228133-1-james.morse@arm.com> <20181203180613.228133-11-james.morse@arm.com> <20181211183634.GO27375@zn.tnic> <56cfa16b-ece4-76e0-3799-58201f8a4ff1@arm.com> <20190111120322.GD4729@zn.tnic> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190111_094537_590783_392048BD X-CRM114-Status: GOOD ( 11.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rafael Wysocki , Tony Luck , Fan Wu , linux-mm@kvack.org, Marc Zyngier , Catalin Marinas , Xie XiuQi , Will Deacon , Christoffer Dall , Dongjiu Geng , Linux ACPI , James Morse , Naoya Horiguchi , kvmarm@lists.cs.columbia.edu, arm-mail-list , Len Brown Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jan 11, 2019 at 10:32:23AM -0500, Tyler Baicar wrote: > The kernel would have no way of knowing what to do here. What do you mean, there's no way of knowing what to do? It needs to clear registers so that the next error can get reported properly. Or of the status read failed and it doesn't need to do anything, then it shouldn't. Whatever it is, the kernel either needs to do something in the error case to clean up, or nothing if the firmware doesn't need anything done in the error case; *or* ack the error in the success case. This should all be written down somewhere in that GHES v2 spec/doc/writeup whatever, explaining what the OS is supposed to do to signal the error has been read by the OS. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by kanga.kvack.org (Postfix) with ESMTP id 920048E0001 for ; Fri, 11 Jan 2019 12:45:37 -0500 (EST) Received: by mail-wr1-f70.google.com with SMTP id e17so4894781wrw.13 for ; Fri, 11 Jan 2019 09:45:37 -0800 (PST) Received: from mail.skyhub.de (mail.skyhub.de. [2a01:4f8:190:11c2::b:1457]) by mx.google.com with ESMTPS id g10si7306417wrm.253.2019.01.11.09.45.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Jan 2019 09:45:36 -0800 (PST) Date: Fri, 11 Jan 2019 18:45:32 +0100 From: Borislav Petkov Subject: Re: [PATCH v7 10/25] ACPI / APEI: Tell firmware the estatus queue consumed the records Message-ID: <20190111174532.GI4729@zn.tnic> References: <20181203180613.228133-1-james.morse@arm.com> <20181203180613.228133-11-james.morse@arm.com> <20181211183634.GO27375@zn.tnic> <56cfa16b-ece4-76e0-3799-58201f8a4ff1@arm.com> <20190111120322.GD4729@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Tyler Baicar Cc: James Morse , Linux ACPI , kvmarm@lists.cs.columbia.edu, arm-mail-list , linux-mm@kvack.org, Marc Zyngier , Christoffer Dall , Will Deacon , Catalin Marinas , Naoya Horiguchi , Rafael Wysocki , Len Brown , Tony Luck , Dongjiu Geng , Xie XiuQi , Fan Wu On Fri, Jan 11, 2019 at 10:32:23AM -0500, Tyler Baicar wrote: > The kernel would have no way of knowing what to do here. What do you mean, there's no way of knowing what to do? It needs to clear registers so that the next error can get reported properly. Or of the status read failed and it doesn't need to do anything, then it shouldn't. Whatever it is, the kernel either needs to do something in the error case to clean up, or nothing if the firmware doesn't need anything done in the error case; *or* ack the error in the success case. This should all be written down somewhere in that GHES v2 spec/doc/writeup whatever, explaining what the OS is supposed to do to signal the error has been read by the OS. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.