search

riscv-non-isa / riscv-brs

The Boot and Runtime Services (BRS) specification provides the software requirements for system vendors and Operating System Vendors (OSVs) to interoperate with one another by providing expectations for the Operating System (OS) to utilize in acts of device discovery, system management, and other rich operations provided in this specification.
https://jira.riscv.org/browse/RVG-48
Creative Commons Attribution 4.0 International
39 stars 13 forks source link

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

Closed darius-bluespec closed 6 months ago

darius-bluespec commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 6 months ago

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 commented 6 months ago

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.