Re: [PATCH v2] cxl/mbox: Support Media Operation

[Dave Jiang <dave.jiang@intel.com>]

On 4/29/26 12:06 PM, Davidlohr Bueso wrote:
> On Tue, 28 Apr 2026, Dave Jiang wrote:
> 
>> On 4/28/26 1:04 PM, Davidlohr Bueso wrote:
>>> Add support for the Media Operation command (opcode 4402h) which
>>> enables targeted sanitize and zero operations on specific DPA ranges,
>>> as defined in CXL 4.0 Section 8.2.10.9.5.3.
>>>
>>> Operations are only allowed on DPA ranges that do not overlap any
>>> hardware-committed endpoint decoder to ensure not corrupting active
>>> mappings.
>>>
>>> Following the path that we currently impose for background cmds, where
>>> users are left with the responsibility of breaking up work sanely, this
>>> implementation imposes an arbitrary limit of 1Gb range to avoid hogging
>>> locks (ie: region/dpa cannot change while media op is on going) and resource
>>> monopolization such as mbox. As such, background commands are processed
>>> synchronously, with a 30s timeout, and currently, per spec, there is no
>>> optional abort it either, nor a way for the device to inform how long the
>>> op could take, ala Scan Media. The observation is that this differs in
>>> semantics regarding the sanitize case, which for whole-device continues
>>> to be handled asynchronously, as a special case.
>>>
>>> Run Discovery during probe to get the device's DPA range granularity
>>> and which operations are supported, and expose to sysfs accordingly:
>>>
>>>   o 'security/sanitize' is multiplexed to allow single ranged input.
>>
>> Maybe just introduce a new sysfs attrib instead of multiplexing?
>> security/sanitize_range
> 
> I am torn between the two options - I do like just a single file.
> But I also like that its own file eliminates that strange async/sync
> handling, which might be a more important factor to consider. If we did
> this, I would rename zero to zero_range as well, for consistency.

The sysfs kdoc [1] says single value is preferred and if not, multiple of the same value type as an array can be considered. We may be pushing the boundary of same value type with range and length. Either way, probably should split out so it's not multiplexing 'sanitize'.

[1] https://docs.kernel.org/filesystems/sysfs.html

DJ

> 
>>
>>>   o 'security/zero' is added, also with single ranged input.
>>>   o 'security/range_limit' is added so users can see the max range supported.
>>
>> media_op_range_limit?
> 
> Ok
>>
>> Can you split this into 3 patches: discover, sanitize_range enabling, and sanitize_zero?
> 
> Ok
>>
>> Would be great to get some cxl_test coverage on the new added ops.
> 
> Right, so far I have used qemu's support to test, I will add cxl_test coverage
> as a follow up to this work.
> 
> Thanks,
> Davidlohr