Re: [PATCH v2 3/3] tests/intel/xe_ccs : Add CCS corruption neg test for VM_BIND decomp

[Matthew Auld <matthew.auld@intel.com>]

On 22/06/2026 07:08, Balasubramanyam, Smitha wrote:
> 
> On 15/06/2026 13:31, Smitha Balasubramanyam wrote:
>> Add a negative test covering VM_BIND decompression verification with
>> corrupted CCS metadata.
>   > > The test also exercises suspend and resume handling during the
>> corruption scenario.
> 
>> What is meant by corrupted CCS here? Is this userspace corrupting something? If so, why does the kernel care? Can you give some more details here please?
> 
> Sure, this testcase is not primarily a negative uAPI rejection check.
> The testcase exercises behavior when userspace intentionally corrupts CCS metadata, then issues VM_BIND with DECOMPRESS and compares outcomes:
> - corrupted-CCS path is expected to differ from source data
> - clean-CCS path is expected to match source data

Does it really matter if userspace tramples the CCS? I assume we already 
create a compressed surface and check that the decompress flag behaves 
as we expect. If we trample the CCS data, then yes that will be visible 
when we decompress, same as when it contains "normal" data. End result 
is the same with main surface being the uncompressed view taking into 
account whatever was in the CCS data (whether corrupted or not 
corrupted) + main surface, with CCS being updated as uncompressed.

If usespace corrupts the CCS then yes that will be visible when you 
decompress it, but that is the same if they corrupt the main surface 
with random garbage? But is it really worth validating that? I guess it 
not clear what we are actually validating here from kernel/hw pov?

If there is some angle here from hw pov you have in mind, with some kind 
of specially crafted CCS corruption trying to trigger something bad, 
then that sounds more like general CCS coverage, and not part of VM_BIND 
decompress flag? Since the decompress thing can be done just as easily 
from userpace directly. Idea with having the kernel do it, is just that 
in some cases it's in the best position to do it, but there is nothing 
special that the kernel does for the decompress part. Plus that flag is 
not universally supported.

> 
> I agree the current test name may not reflect this intent clearly.
> I can rename it to something more explicit, like below if you suggest :
> - vm-bind-decompress-ccs-corruption-behavior-check or
> - vm-bind-decompress-ccs-corruption-comparison
>