From: Bjorn Helgaas <helgaas@kernel.org>
To: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Cc: helgaas@google.com, austin_bolen@dell.com,
alex_gagniuc@dellteam.com, keith.busch@intel.com,
Shyam_Iyer@Dell.com, lukas@wunner.de,
"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: Re: [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns AER
Date: Tue, 5 Mar 2019 17:16:51 -0600 [thread overview]
Message-ID: <20190305231650.GC215617@google.com> (raw)
In-Reply-To: <20181115231605.24352-1-mr.nuke.me@gmail.com>
On Thu, Nov 15, 2018 at 05:16:01PM -0600, Alexandru Gagniuc wrote:
> 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(-)
I'm pretty sure we do need to do something here, but there was quite a
lot of discussion that didn't seem to really get resolved, so I'm
dropping these for now.
Please repost them with any relevant updates and we'll see if we can
get a consensus that we're going the right direction.
Bjorn
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Cc: alex_gagniuc@dellteam.com, helgaas@google.com,
Sam Bobroff <sbobroff@linux.ibm.com>,
linux-pci@vger.kernel.org, Shyam_Iyer@Dell.com,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-kernel@vger.kernel.org, keith.busch@intel.com,
linux-acpi@vger.kernel.org, lukas@wunner.de,
Oliver O'Halloran <oohall@gmail.com>,
austin_bolen@dell.com, linuxppc-dev@lists.ozlabs.org,
Len Brown <lenb@kernel.org>
Subject: Re: [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns AER
Date: Tue, 5 Mar 2019 17:16:51 -0600 [thread overview]
Message-ID: <20190305231650.GC215617@google.com> (raw)
In-Reply-To: <20181115231605.24352-1-mr.nuke.me@gmail.com>
On Thu, Nov 15, 2018 at 05:16:01PM -0600, Alexandru Gagniuc wrote:
> 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(-)
I'm pretty sure we do need to do something here, but there was quite a
lot of discussion that didn't seem to really get resolved, so I'm
dropping these for now.
Please repost them with any relevant updates and we'll see if we can
get a consensus that we're going the right direction.
Bjorn
next prev parent reply other threads:[~2019-03-05 23:16 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-15 23:16 [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns AER Alexandru Gagniuc
2018-11-15 23:16 ` Alexandru Gagniuc
2018-11-15 23:16 ` Alexandru Gagniuc
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 ` Alexandru Gagniuc
2018-11-15 23:16 ` 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:16 ` Alexandru Gagniuc
2018-11-15 23:16 ` Alexandru Gagniuc
2018-11-15 23:43 ` Keith Busch
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-16 1:49 ` Sinan Kaya
2018-11-16 1:49 ` Sinan Kaya
2018-11-19 16:53 ` Tyler Baicar
2018-11-19 16:53 ` Tyler Baicar
2018-11-19 16:53 ` Keith Busch
2018-11-19 16:53 ` Keith Busch
2018-11-19 17:32 ` Sinan Kaya
2018-11-19 17:32 ` Sinan Kaya
2018-11-19 17:36 ` Keith Busch
2018-11-19 17:36 ` Keith Busch
2018-11-19 17:42 ` Sinan Kaya
2018-11-19 17:42 ` Sinan Kaya
2018-11-19 17:41 ` Keith Busch
2018-11-19 17:41 ` Keith Busch
2018-11-19 17:56 ` Sinan Kaya
2018-11-19 17:56 ` Sinan Kaya
2018-11-19 18:10 ` Keith Busch
2018-11-19 18:10 ` Keith Busch
2018-11-19 18:24 ` Sinan Kaya
2018-11-19 18:24 ` Sinan Kaya
2018-11-19 19:11 ` Alex G.
2018-11-19 19:11 ` Alex G.
2018-11-19 19:32 ` Sinan Kaya
2018-11-19 19:32 ` Sinan Kaya
2018-11-19 20:16 ` Alex_Gagniuc
2018-11-19 20:16 ` Alex_Gagniuc
2018-11-19 20:16 ` Alex_Gagniuc
2018-11-19 20:33 ` Sinan Kaya
2018-11-19 20:33 ` Sinan Kaya
2018-11-19 23:49 ` Alex_Gagniuc
2018-11-19 23:49 ` Alex_Gagniuc
2018-11-19 23:49 ` Alex_Gagniuc
2018-11-20 1:54 ` Sinan Kaya
2018-11-20 1:54 ` Sinan Kaya
2018-11-20 20:44 ` Alex_Gagniuc
2018-11-20 20:44 ` Alex_Gagniuc
2018-11-20 20:44 ` Alex_Gagniuc
2018-11-20 21:02 ` Sinan Kaya
2018-11-20 21:02 ` Sinan Kaya
2018-11-20 21:42 ` Keith Busch
2018-11-20 21:42 ` Keith Busch
2018-11-20 22:28 ` Sinan Kaya
2018-11-20 22:28 ` Sinan Kaya
2018-11-20 22:35 ` Alex G.
2018-11-20 22:35 ` Alex G.
2018-11-20 21:46 ` Alex_Gagniuc
2018-11-20 21:46 ` Alex_Gagniuc
2018-11-20 21:46 ` Alex_Gagniuc
2018-11-20 22:08 ` Sinan Kaya
2018-11-20 22:08 ` Sinan Kaya
2018-11-20 22:36 ` Alex_Gagniuc
2018-11-20 22:36 ` Alex_Gagniuc
2018-11-20 22:36 ` Alex_Gagniuc
2018-11-27 18:22 ` Alex_Gagniuc
2018-11-27 18:22 ` Alex_Gagniuc
2018-11-27 18:22 ` Alex_Gagniuc
2018-11-27 18:32 ` Sinan Kaya
2018-11-27 18:32 ` Sinan Kaya
2018-11-27 18:46 ` Tyler Baicar
2018-11-27 18:46 ` Tyler Baicar
2018-11-16 12:37 ` David Laight
2018-11-16 12:37 ` David Laight
2018-11-16 12:37 ` David Laight
2019-03-05 23:16 ` Bjorn Helgaas [this message]
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=20190305231650.GC215617@google.com \
--to=helgaas@kernel.org \
--cc=Shyam_Iyer@Dell.com \
--cc=alex_gagniuc@dellteam.com \
--cc=austin_bolen@dell.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=mr.nuke.me@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.