[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ea1048ed-7e9c-4ab5-4a05-01cbddae5c19@gmail.com>
Date: Tue, 20 Nov 2018 16:35:34 -0600
From: "Alex G." <mr.nuke.me@...il.com>
To: Sinan Kaya <okaya@...nel.org>, Keith Busch <keith.busch@...el.com>
Cc: Alex_Gagniuc@...lteam.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 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.
Powered by blists - more mailing lists