Re: [ACPI Code First ECN] "Extended-linear" addressing for direct-mapped memory-side caches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 
> 
> > > # Impact of the Change
> > > The proposed "Address Mode" field consumes the 2 Reserved bytes
> > > following the "Cache Attributes" field in the "Memory Side Cache
> > > Information Structure". The default reserved value of 0 indicates the
> > > status quo of an undeclared addressing mode where the expectation is
> > > that it is safe to assume the cache-capacity is transparent to the SRAT
> > > range capacity. An OSPM that knows about new values can consider SPA to
> > > HPA relationships according to the address-layout definition proposed
> > > below. A legacy OSPM will ignore it as a Reserved field.
> > > 
> > > # References
> > > * Compute Express Link Specification v3.1,
> > > <https://www.computeexpresslink.org/>
> > > 
> > > # Detailed Description of the Change  
> > 
> > Probably need to up rev HMAT as well.  
> 
> I'd let the ACPI working group make that determination. I am not clear
> on whether repurposing a reserved field mandates a version bump.

Normally does, but sure ASWG can figure it out.

> 
> > > 
> > > * Section Table 5.149: Memory Side Cache Information Structure redefine
> > >   the 2 Reserved bytes starting at offset 28 as "Address Mode":
> > > 
> > >     * 0 - Reserved (OSPM may assume transparent cache addressing)  
> > 
> > Can we make that assumption?  What are today's firmware's doing for this?  
> 
> The only shipping example I know of was for PMEM.

I gather that there are others, though that is the most common one.

> 
> > I'd drop the 'may assume'  Also after this change it's not reserved.
> > 0 explicitly means transparent cache addressing.  
> 
> I am just going to switch the parenthetical to "(Unknown Address Mode)"
> because "transparent" does not give any actionable information about
> alias layout in the SRAT address space. So system-software can make no
> assumptions about layout without consulting implementation specific
> documentation.

I'd like an option to indicate that we know reported errors will not
involve problems with aliases. Something like...

0 - Unknown (all bets are off, read the manual).
1 - No aliases.
2 - your one.

A simple write-through or write-back cache would not result in aliases
for errors reported by the backing memory.

Assuming we don't get an address corruption (in which case everything
dead anyway as uncontainable error), then poison can come from:
1) poison happens in the memory itself (fine, the DPA in CXL is enough)
2) poison happens in cache and is written back to memory. (fine
   the DPA in CXL is enough).
3) poison happens in cache and is read by host. Synchronous handling and
   the HPA is available and enough.

Not much we can do with 0, but 1 at least lets us know we have the
single right answer.

> 
> > >     * 1 - Extended-linear (N direct-map aliases linearly mapped)
> > >     * 2..65535 - Reserved (Unknown Address Mode)
> > > 
> > > * Extend the implementation note after Table 5.149 to explain how to
> > >   interpret the "Extended-linear" mode.
> > > 
> > >   * When Address Mode is 1 'Extended-Linear' it indicates that the
> > >     associated address range (SRAT.MemoryAffinityStructure.Length) is
> > >     comprised of the backing store capacity extended by the cache
> > >     capacity. It is arranged such that there are N directly addressable
> > >     aliases of a given cacheline where N is the ratio of target memory
> > >     proximity domain size and the memory side cache size. Where the N
> > >     aliased addresses for a given cacheline all share the same result
> > >     for the operation 'address modulo cache size'.  
> > 
> > Probably need more here.  What if someone has two such ranges of size
> > 
> > Address 0, (512G + 64G) , (1024G + 128G)
> > And decides to pack them for some reason.
> > The second one will be aligned to 64G not, 128G so modulo needs to take
> > into account the base address.  
> 
> Decides to pack them how? My expectation in this situation is 2
> proximity domains / memory-side cache descriptions.
> 

I was wrongly thinking the modulo maths failed if not aligned to the
cache size. Ignore this bit.

> > Do we need explicit statement that N is an integer? Probably works anyway
> > but having 2.5 aliases is an unusual concept.  
> 
> Easy enough to add "(integer)" after the first reference of "N".
> 
> > > This setting is only
> > >     allowed when 'Cache Associativity' is 'Direct Map'."  
> > 
> > Other than these corner cases looks good to me and the new terminology and
> > clarifications help a lot.  
> 
> Thanks for the feedback.

No problem.

J
> 





[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]
  Powered by Linux