From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Busch Subject: Re: [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns AER Date: Tue, 20 Nov 2018 14:42:43 -0700 Message-ID: <20181120214243.GG26707@localhost.localdomain> References: <20181119181051.GA26707@localhost.localdomain> <3f923367-2cc1-c0d6-bca6-bf9a03d1b9ca@gmail.com> <84013a8a-287d-d700-6710-91cc35f507c8@kernel.org> <9c9531c7efb846438f03f744b9afc466@ausx13mps321.AMER.DELL.COM> <3b18a9fa-7bdd-0fb4-285d-4efb454be50a@kernel.org> <314e59da-48e1-545b-3ee9-6e5056b90fd9@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <314e59da-48e1-545b-3ee9-6e5056b90fd9@kernel.org> Sender: linux-kernel-owner@vger.kernel.org To: Sinan Kaya Cc: Alex_Gagniuc@Dellteam.com, mr.nuke.me@gmail.com, baicar.tyler@gmail.com, Austin.Bolen@dell.com, Shyam.Iyer@dell.com, lukas@wunner.de, bhelgaas@google.com, rjw@rjwysocki.net, lenb@kernel.org, ruscur@russell.cc, sbobroff@linux.ibm.com, oohall@gmail.com, linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org List-Id: linux-acpi@vger.kernel.org On Tue, Nov 20, 2018 at 04:02:21PM -0500, Sinan Kaya wrote: > On 11/20/2018 3:44 PM, Alex_Gagniuc@Dellteam.com wrote: > > I'd prefer "sure" instead of "think". "I think it breaks some system I'm > > not telling you about" doesn't help much in figuring out how not to > > break said system(s).:) > > Sorry, I thought I mentioned why it would break but let me repeat. > > The systems I have seen rely on the HEST table presence as an indicator > to the OS that firmware first is enabled. If you go look at the _OSC bits > on such systems, it still says OS owns the AER service. > > The assumption here is that HEST table has precedence over the _OSC bits. > That's what needs to be clarified in the UEFI forum. > > If this code is to go in and ignore the HEST table presence, then firmware > will think that it owns AER service and OS will think that it owns AER > service too. How does that work? If the OS takes control, it sets up MSIs that FW don't react to, and disables system errors through PCIe Root Control. Aren't those sys errs the mechanism FW knows it has something to do, which means the OS can effectively fence it off? 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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=unavailable 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 25B8FC28CF8 for ; Tue, 20 Nov 2018 21:47:59 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (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 66D0021479 for ; Tue, 20 Nov 2018 21:47:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 66D0021479 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 42zzpN33KrzF3b7 for ; Wed, 21 Nov 2018 08:47:56 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=intel.com (client-ip=134.134.136.20; helo=mga02.intel.com; envelope-from=keith.busch@intel.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=intel.com Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 42zzmD3D8mzF3PQ for ; Wed, 21 Nov 2018 08:46:00 +1100 (AEDT) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2018 13:45:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,258,1539673200"; d="scan'208";a="107936095" Received: from unknown (HELO localhost.localdomain) ([10.232.112.69]) by fmsmga004.fm.intel.com with ESMTP; 20 Nov 2018 13:45:57 -0800 Date: Tue, 20 Nov 2018 14:42:43 -0700 From: Keith Busch To: Sinan Kaya Subject: Re: [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns AER Message-ID: <20181120214243.GG26707@localhost.localdomain> References: <20181119181051.GA26707@localhost.localdomain> <3f923367-2cc1-c0d6-bca6-bf9a03d1b9ca@gmail.com> <84013a8a-287d-d700-6710-91cc35f507c8@kernel.org> <9c9531c7efb846438f03f744b9afc466@ausx13mps321.AMER.DELL.COM> <3b18a9fa-7bdd-0fb4-285d-4efb454be50a@kernel.org> <314e59da-48e1-545b-3ee9-6e5056b90fd9@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <314e59da-48e1-545b-3ee9-6e5056b90fd9@kernel.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alex_Gagniuc@Dellteam.com, baicar.tyler@gmail.com, sbobroff@linux.ibm.com, linux-pci@vger.kernel.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, Shyam.Iyer@dell.com, linux-acpi@vger.kernel.org, lukas@wunner.de, oohall@gmail.com, mr.nuke.me@gmail.com, Austin.Bolen@dell.com, bhelgaas@google.com, linuxppc-dev@lists.ozlabs.org, lenb@kernel.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tue, Nov 20, 2018 at 04:02:21PM -0500, Sinan Kaya wrote: > On 11/20/2018 3:44 PM, Alex_Gagniuc@Dellteam.com wrote: > > I'd prefer "sure" instead of "think". "I think it breaks some system I'm > > not telling you about" doesn't help much in figuring out how not to > > break said system(s).:) > > Sorry, I thought I mentioned why it would break but let me repeat. > > The systems I have seen rely on the HEST table presence as an indicator > to the OS that firmware first is enabled. If you go look at the _OSC bits > on such systems, it still says OS owns the AER service. > > The assumption here is that HEST table has precedence over the _OSC bits. > That's what needs to be clarified in the UEFI forum. > > If this code is to go in and ignore the HEST table presence, then firmware > will think that it owns AER service and OS will think that it owns AER > service too. How does that work? If the OS takes control, it sets up MSIs that FW don't react to, and disables system errors through PCIe Root Control. Aren't those sys errs the mechanism FW knows it has something to do, which means the OS can effectively fence it off?