Jonathan Cameron wrote: > On Mon, 1 Jul 2024 15:54:41 -0700 > Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > > > # Title: "Extended-linear" addressing for direct-mapped memory-side caches > > > > # Status: v4 > > > > # Document: ACPI Specification 6.6 > > > > # License > > SPDX-License Identifier: CC-BY-4.0 > > > > # Submitter: > > * Sponsor: Dan Williams, Intel > > * Creators/Contributors: > > * Andy Rudoff, retired > > * Mahesh Natu, Intel > > * Ishwar Agarwal, Intel > > > > # Changelog > > * v4: Drop "improved cache utilization" claim (Jonathan) > > * v4: Clarify SPA vs HPA terminology > > * v4: Clarify possibility and difficulty of multiple CPER records to > > communicate aliases (Jonathan) > > * v4: Clarify that N is expected to be an integer ration of "near" to > > "far" memory. (Jonathan) > > * v3: Replace "Inclusive Linear" with "Extended-linear" term, and > > clarify the SPA vs HPA behavior of this cache addressing mode. > > (Jonathan) > > * v2: Clarify the "Inclusive" term as "including the capacity of the cache > > in the SRAT range length" > > * v2: Clarify that 0 is an undeclared / transparent Address Mode, and > > that Address Mode values other than 1 are Reserved. > > > > v3: http://lore.kernel.org/6650e4f835a0e_195e294a8@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.notmuch > > v2: http://lore.kernel.org/663ea70884cfd_db82d29414@xxxxxxxxxxxxxxxxxxxxxxxxx.notmuch > > > Trivial suggestions inline. > > Otherwise seems fine to me. > > Jonathan [..] > > # Benefits of the Change > > Without this change an OSPM that encounters a memory-side cache > > configuration of DDR fronting CXL may not understand that an SRAT range > > extended by cache capacity should be maintained as one contiguous SPA > > range even though the CXL HPA decode configuration only maps a subset of > > the SRAT SPA range. In other words the memory-side-cache dynamically > > maps access to that SPA range to either a CXL or DDR HPA. > > > > Without this change the only way for system software to become aware of > > the fact that one memory poison event implicates multiple address > > locations would be for multiple error records (CPER) to be emitted > > multiple error record sections (one CPER can contain a bunch of those). Noted. > > per-poison consumption event. That may surprise existing OSPM > > implementations. > > I'd be tempted to add one line say that obviously this is impossible > for OS first handling as no one there to generate the records. That > is kind of implied, but might as well say it. > As I understand this proposal is already under ASWG consideration so I am pausing on any other editorial updates here awaiting that result. Thanks for the feedback Jonathan.
