ACPI_050/040 are too much (Was: Some optional requirements are written in an inflexible way)

[darius-bluespec]

Requirements are stated in a way that precludes vendor specific
behavior in certain cases.

For example, "the PCI Memory-mapped Configuration Space (MCFG) table
must only be present if and only if compatible non-hot-removable PCIe
segments are made available to the OS." Thus, implementors have the
option of (1) not implementing that feature, (2) implementing it
exactly as described, or (3) being out of compliance with the entire
specification. There is no latitude to comply with the BRS and
provide that feature in a vendor specific way.

Contrast to the way that ISA extensions are defined, considering for
example floating point (F&D). An implementation may (1) not implement
floating point, (2) implement floating point as described by the F&D
extensions, or (3) implement floating point in any other way. All
three options are compliant with the ISA specification. The only
prohibition is that option (3) cannot assert that it implements the
F&D extensions.

[andreiw]

MCFG use specifically has implications on the implementations... the current ACPI language around PCIe allows crazy non-ECAM-compliant things, they just can't be exposed in a way that violates the PCIe FW spec by using MCFG (as has been done on countless Arm systems, for e.g).

So to address your point, the spec does allow for an implementation of a feature in a BRS-compliant way, so long as it the implementation doesn't abuse a standard mechanism for something, relying on OS hacks to work.

[adurbin-rivos]

I think the current description could be better clarified if we're tying things to the PCIe FW spec. I see the citations, but we aren't calling out those specific requirements in what is written now. I suggest we say compliant with PCIe FW spec, basically.

That said, I think BRS is supposed to contain best practices based on experience. It is true there were issues relating to MCFG on certain systems. As such, I think we should call out the requirements to not allow for missteps.

[darius-bluespec]

One person's "abuse" and "OS hack" is another person's "vendor specific behavior". I don't particularly care about this specific case, but I am concerned about setting a precedent of overly constraining optional requirements and limiting flexibility for vendor specific behavior. It seems excessive in the BRS Specification; perhaps more appropriate in a platform specification. The problem with unnecessarily overconstraining things is that the requirements get ignored and the specification loses credibility.

[andreiw]

I think the current description could be better clarified if we're tying things to the PCIe FW spec. I see the citations, but we aren't calling out those specific requirements in what is written now. I suggest we say compliant with PCIe FW spec, basically.

That said, I think BRS is supposed to contain best practices based on experience. It is true there were issues relating to MCFG on certain systems. As such, I think we should call out the requirements to not allow for missteps.

I like this approach.

Hijacking this issue to clean up the MCFG issue you highlighted... if you see other instances where we are being needlessly specific instead of deferring to the right spec, let us know.

[andreiw]

One person's "abuse" and "OS hack" is another person's "vendor specific behavior". I don't particularly care about this specific case, but I am concerned about setting a precedent of overly constraining optional requirements and limiting flexibility for vendor specific behavior. It seems excessive in the BRS Specification; perhaps more appropriate in a platform specification. The problem with unnecessarily overconstraining things is that the requirements get ignored and the specification loses credibility.

BRS-I is very much about avoiding vendor specific behavior that violates an industry spec. You can still write your own custom code. Just don't violate the PCIFW by abusing a specific ACPI table reserved for compliant implementations. It's worth highlighting this as a requirement...while you'd think it's common sense, what happened with AArch64 and ACPI support begs to differ.