Re: [PATCH v2 1/3] tests/intel/xe_ccs : Add helpers and Negative test for VM_Bind Decomp

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

On 22/06/2026 06:24, Balasubramanyam, Smitha wrote:
> 
> On 15/06/2026 18:02, Matthew Auld wrote:
>> On 15/06/2026 13:31, Smitha Balasubramanyam wrote:
>>> Introduce data structures and helper utilities used by the VM
>>> negative tests to validate the VM_Bind Decomp feature
>>>
>>> These helpers provide resource management and setup/cleanup logic
>>> that simplifies the implementation of the test cases introduced in
>>> subsequent patches.
>>>
>>> One functional subtest is introduced in this patch.
>>> This test verifies handling of invalid UAPI Params in Non-fault Mode.
>>
>> Why is there so much code being added in this series? The negative
>> tests should just be checking that an ioctl gets rejected, when doing
>> various bogus things? Series is adding like +1000 lines of code? What am I missing?
> 
>> Also, if we do need all of this, can we not extend the existing code in some way to handle the negative tests?
> 
> Thanks for the feedback.
> 
> The major bloat in patch 1 is coming from the two positive cases I included in the bad-params test (decompress-default-pat and decompress-gpu-wb-pat).
> For those cases, I was not just checking ioctl outcome, but also doing full mmap + pattern verification + memcmp, which is really positive-test coverage.
> I plan to move those out into a separate follow-up patch.
> 
> For the fault-mode bad-params case, the invalid parameter combinations themselves are the same as the non-fault-mode case.
> I split them in v1 mainly because that follows the current pattern already present in xe_ccs.c, where fault and non-fault positive paths are separate.
> To reduce duplication, I plan to fold the fault-mode and non-fault-mode bad-params coverage into a single implementation driven by a config flag,
> with separate subtest entry points. Please let me know if this is in the right direction.
> 
> I initially wanted to keep the negative test self-contained, but I also see that the setup is almost common between the positive and negative paths.
> So, to contain the code bloat, I plan to refactor the existing positive non-fault case first and then reuse the common setup pieces from there.
> Please let me know if this is in the right direction.
> 

Yeah, code re-use would be good, if possible. I think to make this 
easier to review it might make sense to just keep the scope to negative 
tests, and maybe any extra coverage as another series, if possible. Or 
at the very least split out more stuff into separate patches.

> 
>