On Wed, Jul 09, 2025 at 10:22:40PM -0700, dan.j.williams@xxxxxxxxx wrote: > "Regular?", no. Something is wrong if you are doing this regularly. In > current CXL systems the expectation is to suffer a WBINVD event once per > server provisioning event. Ok, so how about we strictly track this once, and when it happens more than this once, we error out hard? > Now, there is a nascent capability called "Dynamic Capacity Devices" > (DCD) where the CXL configuration is able to change at runtime with > multiple hosts sharing a pool of memory. Each time the physical memory > capacity changes, cache management is needed. > > For DCD, I think the negative effects of WBINVD are a *useful* stick to > move device vendors to stop relying on software to solve this problem. > They can implement an existing CXL protocol where the device tells CPUs > and other CXL.cache agents to invalidate the physical address ranges > that the device owns. > > In other words, if WBINVD makes DCD inviable that is a useful outcome > because it motivates unburdening Linux long term with this problem. Per the above, I suggest we not support this feature *AT*ALL* until an alternative to WBINVD is provided. > In the near term though, current CXL platforms that do not support > device-initiated-invalidate still need coarse cache management for that > original infrequent provisioning events. Folks that want to go further > and attempt frequent DCD events with WBINVD get to keep all the pieces. I would strongly prefer those pieces to include WARNs and or worse.
