CXL.memory deals with physical memory, not virtual memory, akin to the memory controllers on CPUs. Protection mechanisms like rings and segmentation are CPU mechanisms, not those of memory controllers. Are the PIDs you're referring to Process Identifiers? Those are OS assigned; memory controllers do not have visibility into virtual memory field definitions. Physical memory management include operations like interleaving. CXL also includes peer-to-peer device memory access without host interaction. CXL.memory does track and enforce host and device ownership, but, again, that's physical memory, not virtual memory.
Lisa Su announces AI Ryzen Chips, Game Changer?
- Thread starter Arthur Hanson
- Start date
You are not thinking through how complex this becomes with thousands of cores and hundreds of customers in a rack. Every customer needs a separate logical space. Every CPU comes in on a separate port. What you see as a physical address is just a convention, which the switch will manipulate along with port and PID and upper address bits to construct mappings to the subset of resources you actually have access to. This map is not constant because VMs and containers come and go, and resources are allocated and released. The switch becomes a crucial leverage point for managing resources - a form of virtualization.
If CXL expects to scale to racks never mind data centers this is the level of functionality required. The switch will be a key part of the cloud fabric. This is just the CXL equivalent to what happened to IP switching.
If CXL expects to scale to racks never mind data centers this is the level of functionality required. The switch will be a key part of the cloud fabric. This is just the CXL equivalent to what happened to IP switching.
That isn't how CXL works or how memory controllers work. Download the 3.0 spec and read it for yourself. (It's only 911 pages. Light reading.) It looks like you also need a primer on computer architecture.
CXL® Specification - Compute Express Link
Download an Evaluation Copy of the CXL® 3.2 SpecificationPlease review the below and indicate your acceptance to receive immediate access to the Compute Express Link® Specification 3.2.COMPUTE EXPRESS LINK CONSORTIUM, INC.EVALUATION COPY AGREEMENT – as of November 10, 2020THIS EVALUATION COPY...
www.computeexpresslink.org
I was briefed on CXL before it was public, contributed guidance to its creators (still friends of mine) especially on .mem, isolation and security issues, since I was already working on disaggregated memory using CCIXX and CXL needed to catch up. I've kept up on the specs. Some of the diagrams used in CXL presentations on disaggregated memory were originally authored by me.
I have practical experience architecting servers, racks, and various subsystems which now count millions of machines. I've read every edition of CA:AQA and many others besides. You might want to reread my description of what really happens, again and think about how CPUs and individual busses are just components of a bigger system needed to build a modern cloud. Standards get virtualized, that is how large multiuser systems are built.
Over and out, thanks.
I have practical experience architecting servers, racks, and various subsystems which now count millions of machines. I've read every edition of CA:AQA and many others besides. You might want to reread my description of what really happens, again and think about how CPUs and individual busses are just components of a bigger system needed to build a modern cloud. Standards get virtualized, that is how large multiuser systems are built.
Over and out, thanks.
You're familiar with the CXL 3.0 specification and you've read all six or seven editions of the Hennessy/Patterson book? Perhaps you could explain the isolation and security features that are in the 3.0 spec?
By the way, I'm sure it's just a typo, but it's CCIX, not CCIXX.