On Wednesday, August 27, 2025 10:23:46 PM Central European Summer Time Gregory Price wrote: > On Wed, Aug 20, 2025 at 05:06:39PM +0200, Fabio M. De Francesco wrote: > > + > > +E.g, a real x86 platform with two CFMWS, 384 GB total memory, and LMH > > +starting at 2 GB: > > + > > +Window | CFMWS Base | CFMWS Size | HDM Decoder Base | HDM Decoder Size | Ways | Granularity > > + 0 | 0 GB | 2 GB | 0 GB | 3 GB | 12 | 256 > > + 1 | 4 GB | 380 GB | 0 GB | 380 GB | 12 | 256 > > + > > This may be a dumb question, but... how is validation supposed to work? > > Like in theory according to the above something like the following would > also be valid: > > Window | CFMWS Base | CFMWS Size | HDM Decoder Base | HDM Decoder Size > 0 | 4 GB | 380 GB | 2 GB | 382 GB > I'm sorry, it seems that a mistake with copy/pasting I made has led you to hypothesize a case that is out of scope of this document. A case like the one you described will still lead the CXL driver to fail. Please refer to my reply to Robert and to an old email from Dan.[1][2] Thanks, Fabio [1] https://lore.kernel.org/linux-cxl/4179950.vuYhMxLoTh@fdefranc-mobl3/ [2] https://lore.kernel.org/linux-cxl/67ec4d61c3fd6_288d2947b@xxxxxxxxxxxxxxxxxxxxxxxxx.notmuch/ > > (ignoring ways/granularity, i didn't adjust those). > > The entirety of the CFMWS would be contained within the HDM decoder, but > with carve-outs on either end. This would be "allowed" according to the > logic here. > > This would effectively allow all HDM decoder base/size values to be valid > as long as one CFMWS is contained entirely within it. > > As a result, wouldn't it then also be valid to have an HDM Decoder cover > more than one CFMWS range (two full CFMWS described by a single HDM > decoder). > > That seems like it could cause issues. > > ~Gregory > >
