linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexandru Gagniuc <mr.nuke.me@gmail.com>
To: helgaas@google.com
Cc: austin_bolen@dell.com, alex_gagniuc@dellteam.com,
	keith.busch@intel.com, Shyam_Iyer@Dell.com, lukas@wunner.de,
	Alexandru Gagniuc <mr.nuke.me@gmail.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>, Russell Currey <ruscur@russell.cc>,
	Sam Bobroff <sbobroff@linux.ibm.com>,
	"Oliver O'Halloran" <oohall@gmail.com>,
	linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns AER
Date: Thu, 15 Nov 2018 17:16:01 -0600	[thread overview]
Message-ID: <20181115231605.24352-1-mr.nuke.me@gmail.com> (raw)

Thanks to Keith for pointing out that it doesn't make sense to disable
AER services when only one device has a FIRMWARE_FIRST HEST.

AER ownership is an interesting issue brought in by FFS (firmware-first)
model. In a nutshell if FFS handles AER, then OS should not touch any
of the AER bits. FW might set things up so that it receives AER
notifications via SMI. It's theoretically possible to receive SCIs,
but the exact mechanism is platform-dependent. OS touching AER bits
when firmware owns them may interfere with these notifications.

The ACPI mechanism for negotiating control of AER is _OSC, and is
described in detail in ACPI 6.2 Ch. 6.2.11.3. _OSC is negotiated at
the root bus level. Any root port, switch, or endpoint under the bus
would have its AER ownership negotiated in one _OSC call.

Then there is HEST, which is part of ACPI Platform Error Interfaces
(APEI). HEST tables describe the errors that FW may report to the OS.
A types 6,7 and 7 HEST tables describe AER errors from PCIe devices.
As part of this description, we're told if the error source is FFS.

Information in HEST seems to be redundant, as each error reported by
FW will have a CPER table that describes it in detail.

Because HEST describes an error source as firmware-first or not, we've
taken this to mean ownership of AER. Because AER ownership and error
reporting are coupled, _OSC and HEST usually agree on the matter of
ownership. However, that doesn't seem to be required by ACPI.

I've asked around a few people at Dell and they unanimously agree that
_OSC is the correct way to determine ownership of AER. In linux, we
use the result of _OSC to enable AER services, but we use HEST to
determine AER ownership. That's inconsistent. This series drops the
use of HEST in favor of _OSC.

[1] https://lkml.org/lkml/2018/11/15/62

Alexandru Gagniuc (2):
  PCI/AER: Do not use APEI/HEST to disable AER services globally
  PCI/AER: Determine AER ownership based on _OSC instead of HEST

 drivers/acpi/pci_root.c  |  9 +----
 drivers/pci/pcie/aer.c   | 82 ++--------------------------------------
 include/linux/pci-acpi.h |  6 ---
 3 files changed, 5 insertions(+), 92 deletions(-)

-- 
2.17.1


             reply	other threads:[~2018-11-15 23:16 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-15 23:16 Alexandru Gagniuc [this message]
2018-11-15 23:16 ` [PATCH 1/2] PCI/AER: Do not use APEI/HEST to disable AER services globally Alexandru Gagniuc
2018-11-15 23:16 ` [PATCH 2/2] PCI/AER: Determine AER ownership based on _OSC instead of HEST Alexandru Gagniuc
2018-11-15 23:43   ` Keith Busch
2018-11-16  1:49 ` [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns AER Sinan Kaya
2018-11-19 16:53   ` Tyler Baicar
2018-11-19 16:53     ` Keith Busch
2018-11-19 17:32       ` Sinan Kaya
2018-11-19 17:36         ` Keith Busch
2018-11-19 17:42         ` Sinan Kaya
2018-11-19 17:41           ` Keith Busch
2018-11-19 17:56             ` Sinan Kaya
2018-11-19 18:10               ` Keith Busch
2018-11-19 18:24                 ` Sinan Kaya
2018-11-19 19:11                   ` Alex G.
2018-11-19 19:32                     ` Sinan Kaya
2018-11-19 20:16                       ` Alex_Gagniuc
2018-11-19 20:33                         ` Sinan Kaya
2018-11-19 23:49                           ` Alex_Gagniuc
2018-11-20  1:54                             ` Sinan Kaya
2018-11-20 20:44                               ` Alex_Gagniuc
2018-11-20 21:02                                 ` Sinan Kaya
2018-11-20 21:42                                   ` Keith Busch
2018-11-20 22:28                                     ` Sinan Kaya
2018-11-20 22:35                                       ` Alex G.
2018-11-20 21:46                                   ` Alex_Gagniuc
2018-11-20 22:08                                     ` Sinan Kaya
2018-11-20 22:36                                       ` Alex_Gagniuc
2018-11-27 18:22                                       ` Alex_Gagniuc
2018-11-27 18:32                                         ` Sinan Kaya
2018-11-27 18:46                                           ` Tyler Baicar
2018-11-16 12:37 ` David Laight
2019-03-05 23:16 ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181115231605.24352-1-mr.nuke.me@gmail.com \
    --to=mr.nuke.me@gmail.com \
    --cc=Shyam_Iyer@Dell.com \
    --cc=alex_gagniuc@dellteam.com \
    --cc=austin_bolen@dell.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@google.com \
    --cc=keith.busch@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lukas@wunner.de \
    --cc=oohall@gmail.com \
    --cc=rjw@rjwysocki.net \
    --cc=ruscur@russell.cc \
    --cc=sbobroff@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).