Re: [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns AER

From: Sinan Kaya
Date: Mon Nov 19 2018 - 15:33:59 EST


On 11/19/2018 3:16 PM, Alex_Gagniuc@xxxxxxxxxxxx wrote:
On 11/19/2018 01:32 PM, Sinan Kaya wrote:
ACPI 6.2:

18.3.2.4 PCI Express Root Port AER Structure

Flags:

Bit [0] - FIRMWARE_FIRST: If set, this bit indicates to the OSPM that system
firmware will handle errors from this source first.
Bit [1] - GLOBAL: If set, indicates that the settings contained in this
structure apply globally to all PCI Express Devices.
All other bits must be set to zero.

It doesn't say shall, may or might. It says will.

It says "system firmware will handle errors". It does not say "system
firmware owns AER registers". In absence on any descriptor text on the
meaning of these tables, this really looks to me like it should be
interpreted as a descriptor of APEI error sources, not a mutex on who
writes to certain bits-- AER in this case.

True. I was trying to get it out in a rush. I omitted words.

However; table assumes governance about for which entities firmware first
should be enabled. There is no cross reference to _OSC or permission
negotiation like _OST.


I don't think that is contradictory or inconsistent.
I also wasn't able to find any reference to HEST in UEFI 2.7, only in
ACPI spec.

You are right. It was a confusion on my side. The right place to look is
ACPI specification. I was involved in this a couple of years ago. Some pieces
were in UEFI spec. Other pieces were in ACPI. I guess they got unified
now.


I think It depends on your PCI topology.

For other topologies with multiple PCI root complexes, I can see this being
used per root complex flag to indicate which root complex needs firmware first
and which one doesn't.

_OSC is per root bus, so it's already granular enough, right? Why would
it depend on PCI topology?


I was speculating. I don't have the full background on this. Need to consult
the spec developers.

As I said in my previous email, the right place to talk about this is UEFI
forum.

The way I would present the problem to he spec writers is that, although
the spec appears to be consistent, we've seen firmware vendors that made
the wrong assumptions about HEST/_OSC. Instead of describing AER
ownership with _OSC, they attempted to do it with HEST. So we should add
an implementation note, or clarification about this.

I agree.


Alex