All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex G." <mr.nuke.me@gmail.com>
To: Sinan Kaya <okaya@kernel.org>, Keith Busch <keith.busch@intel.com>
Cc: Alex_Gagniuc@Dellteam.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
Subject: Re: [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns AER
Date: Tue, 20 Nov 2018 16:35:34 -0600	[thread overview]
Message-ID: <ea1048ed-7e9c-4ab5-4a05-01cbddae5c19@gmail.com> (raw)
In-Reply-To: <bace940c-70d9-6631-9818-43338d194327@kernel.org>



On 11/20/2018 04:28 PM, Sinan Kaya wrote:
> On 11/20/2018 4:42 PM, Keith Busch wrote:
>> 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?
> 
> I think this is all implementation detail and doesn't necessarily apply
> to all firmware-first implementation flavors.
> 
> Assumptions are:
> 1. both FW and OS are listening to MSI interrupts

On hax86, I'm not sure FW can listen to MSI interrups. FW only exists in 
SMM, not ring 1-4.

> 2. FW monitors the system errors
> 
> Some FF implementation could route the AER interrupt to a higher privilege
> level. Some other implementation could use INTx or a side-band channel 
> interrupt
> for firmware-interrupt too.
> 
> I have seen all 3 except MSI :) and also firmware never monitored the 
> system
> error bits. I was curious if anybody ever used those legacy bits. Now, I 
> know
> someone is using it.

WARNING: multiple messages have this Message-ID (diff)
From: "Alex G." <mr.nuke.me@gmail.com>
To: Sinan Kaya <okaya@kernel.org>, Keith Busch <keith.busch@intel.com>
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, Austin.Bolen@dell.com, bhelgaas@google.com,
	linuxppc-dev@lists.ozlabs.org, lenb@kernel.org
Subject: Re: [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns AER
Date: Tue, 20 Nov 2018 16:35:34 -0600	[thread overview]
Message-ID: <ea1048ed-7e9c-4ab5-4a05-01cbddae5c19@gmail.com> (raw)
In-Reply-To: <bace940c-70d9-6631-9818-43338d194327@kernel.org>



On 11/20/2018 04:28 PM, Sinan Kaya wrote:
> On 11/20/2018 4:42 PM, Keith Busch wrote:
>> 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?
> 
> I think this is all implementation detail and doesn't necessarily apply
> to all firmware-first implementation flavors.
> 
> Assumptions are:
> 1. both FW and OS are listening to MSI interrupts

On hax86, I'm not sure FW can listen to MSI interrups. FW only exists in 
SMM, not ring 1-4.

> 2. FW monitors the system errors
> 
> Some FF implementation could route the AER interrupt to a higher privilege
> level. Some other implementation could use INTx or a side-band channel 
> interrupt
> for firmware-interrupt too.
> 
> I have seen all 3 except MSI :) and also firmware never monitored the 
> system
> error bits. I was curious if anybody ever used those legacy bits. Now, I 
> know
> someone is using it.

  reply	other threads:[~2018-11-20 22:35 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. [this message]
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
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=ea1048ed-7e9c-4ab5-4a05-01cbddae5c19@gmail.com \
    --to=mr.nuke.me@gmail.com \
    --cc=Alex_Gagniuc@Dellteam.com \
    --cc=Austin.Bolen@dell.com \
    --cc=Shyam.Iyer@dell.com \
    --cc=baicar.tyler@gmail.com \
    --cc=bhelgaas@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=okaya@kernel.org \
    --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.