[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bace940c-70d9-6631-9818-43338d194327@kernel.org>
Date: Tue, 20 Nov 2018 17:28:49 -0500
From: Sinan Kaya <okaya@...nel.org>
To: Keith Busch <keith.busch@...el.com>
Cc: Alex_Gagniuc@...lteam.com, mr.nuke.me@...il.com,
baicar.tyler@...il.com, Austin.Bolen@...l.com, Shyam.Iyer@...l.com,
lukas@...ner.de, bhelgaas@...gle.com, rjw@...ysocki.net,
lenb@...nel.org, ruscur@...sell.cc, sbobroff@...ux.ibm.com,
oohall@...il.com, linux-pci@...r.kernel.org,
linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns
AER
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
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.
Powered by blists - more mailing lists