Re: [PATCH i-g-t 0/2] test/intel/xe_vm: Add overcommit and no‑overcommit handling tests

["Hellstrom, Thomas" <thomas.hellstrom@intel.com>]

On Tue, 2026-02-17 at 14:57 +0100, Thomas Hellström wrote:
> Hi, Thomas,
> 
> On Thu, 2026-02-12 at 19:03 +0000, Sobin Thomas wrote:
> > This series adds coverage to xe_vm test by adding over commit test
> > in
> > fault mode and
> > non fault mode.
> > Also added support to test the no overcommit flag
> > (DRM_XE_VM_CREATE_NO_VM_OVERCOMMIT)
> > 
> > Sobin Thomas (2):
> >   tests/intel/xe_vm: overcommit tests for fault-mode and non-fault-
> > mode
> >     VMs
> >   test/intel/xe_vm: Test to check no overcommit flag in fault mode
> > 
> >  include/drm-uapi/xe_drm.h |   1 +
> >  tests/intel/xe_vm.c       | 634
> > +++++++++++++++++++++++++++++++++++++-
> >  2 files changed, 630 insertions(+), 5 deletions(-)
> 
> I wonder, is it possible to create a single test for the different
> modes and select the different modes with flags? The following should
> hold for bos in VRAM:
> 
> 1. DRM_XE_VM_CREATE_FLAG_LR_MODE:
> a) If bos are created in VRAM only and either local to the VM or
> created with the flag DRM_XE_GEM_CREATE_FLAG_DEFER_BACKING, then
> overcommit is not allowed. Compute is relying on this and this is
> what
> "test_oom" tests.
> b) If bos are created external and without the flag
> DRM_XE_GEM_CREATE_FLAG_DEFER_BACKING, overcommit is allowed but will
> error on first exec.
> 
> 2. DRM_XE_VM_CREATE_FLAG_LR_MODE | DRM_XE_VM_CREATE_FLAG_FAULT_MODE:
> Overcommit is always allowed. Should not error on exec.
> 
> 3. !DRM_XE_VM_CREATE_FLAG_LR_MODE:
> Overcommit is always allowed. Should error on exec if overcommited.
> 
> 4. DRM_XE_VM_CREATE_FLAG_LR_MODE | DRM_XE_VM_CREATE_FLAG_FAULT_MODE:
>    DRM_XE_VM_CREATE_FLAG_NO_VM_OVERCOMMIT.
> Should behave just like 1.)

Except it should not fail on first exec.

> 
> So it should be possible to create an array with VM create flags, bo
> create mode and expected results and use a single test?
> 
> For bos in system memory the above should also hold but with the
> additional problem that it is likely that the oom killer is hit. In
> particular with systems without swap.
> 
> Thanks,
> Thomas
> 
>