[PATCH i-g-t v6 13/17] tests/xe_eudebug: Test eudebug resource tracking and manipulation

[Zbigniew Kempczyński]

On Tue, Sep 17, 2024 at 06:00:51PM +0200, Manszewski, Christoph wrote:
> Hi Zbigniew,
> 
> On 12.09.2024 10:04, Zbigniew Kempczyński wrote:
> > On Thu, Sep 05, 2024 at 11:28:08AM +0200, Christoph Manszewski wrote:
> > > From: Dominik Grzegorzek <dominik.grzegorzek at intel.com>
> > > 
> > > For typical debugging under gdb one can specify two main usecases:
> > > accessing and manupulating resources created by the application and
> > > manipulating thread execution (interrupting and setting breakpoints).
> > > 
> > > This test adds coverage for the former by checking that:
> > > - the debugger reports the expected events for Xe resources created
> > > by the debugged client,
> > > - the debugger is able to read and write the vm of the debugged client.
> > 
> > Hi all.
> > 
> > First of all, on Mika series (v2) sent upstream on xe ml I've noticed
> > some tests are crashing the kernel. From this test perspective this is
> > good, it seems test is doing what it should do. I observe reboot on
> > vm access related subtests: basic-vm-access(-userptr).
> > 
> > > 
> > > Signed-off-by: Dominik Grzegorzek <dominik.grzegorzek at intel.com>
> > > Signed-off-by: Mika Kuoppala <mika.kuoppala at linux.intel.com>
> > > Signed-off-by: Christoph Manszewski <christoph.manszewski at intel.com>
> > > Signed-off-by: Karolina Stolarek <karolina.stolarek at intel.com>
> > > Signed-off-by: Maciej Patelczyk <maciej.patelczyk at intel.com>
> > > Signed-off-by: Pawel Sikora <pawel.sikora at intel.com>
> > > Signed-off-by: Andrzej Hajda <andrzej.hajda at intel.com>
> > > Signed-off-by: Dominik Karol Piątkowski <dominik.karol.piatkowski at intel.com>
> > > Signed-off-by: Jonathan Cavitt <jonathan.cavitt at intel.com>
> > > ---
> > >   docs/testplan/meson.build |   13 +-
> > >   meson_options.txt         |    2 +-
> > >   tests/intel/xe_eudebug.c  | 2716 +++++++++++++++++++++++++++++++++++++
> > >   tests/meson.build         |    8 +
> > >   4 files changed, 2737 insertions(+), 2 deletions(-)
> > >   create mode 100644 tests/intel/xe_eudebug.c
> > > 
> 
> <cut>
> 
> > > +
> > > +static void vm_bind_clear_test_trigger(struct xe_eudebug_debugger *d,
> > > +				       struct drm_xe_eudebug_event *e)
> > > +{
> > > +	struct drm_xe_eudebug_event_vm_bind_op *eo = (void *)e;
> > > +	struct vm_bind_clear_priv *priv = d->ptr;
> > > +
> > > +	if (e->flags & DRM_XE_EUDEBUG_EVENT_CREATE) {
> > > +		if (random() & 1) {
> > 
> > What's that random() doing here?
> 
> Apparently this test is supposed to catch a race, where either the client or
> the debugger see some leftover in a new bind. To increase the chance of this
> happening, we need to skip the debugger's vm_open on a preceeding iteration,
> since otherwise we slow down/defer the subsequent bind.

I would add some igt_debug() to get the context in which "random" part
test was executed. This will make it reproducing easier.

--
Zbigniew

> 
> Thanks,
> Christoph
> > 
> > > +			struct drm_xe_eudebug_vm_open vo = { 0, };
> > > +			uint32_t v = 0xc1c1c1c1;
> > > +
> > > +			struct drm_xe_eudebug_event_vm_bind *eb;
> > > +			int fd, delta, r;
> > > +
> > > +			igt_debug("vm bind op event received with ref %lld, addr 0x%llx, range 0x%llx\n",
> > > +				  eo->vm_bind_ref_seqno, eo->addr, eo->range);
> > > +
> > > +			eb = (struct drm_xe_eudebug_event_vm_bind *)
> > > +				xe_eudebug_event_log_find_seqno(d->log, eo->vm_bind_ref_seqno);
> > > +			igt_assert(eb);
> > > +
> > > +			vo.client_handle = eb->client_handle;
> > > +			vo.vm_handle = eb->vm_handle;
> > > +
> > > +			fd = igt_ioctl(d->fd, DRM_XE_EUDEBUG_IOCTL_VM_OPEN, &vo);
> > > +			igt_assert_lte(0, fd);
> > > +
> > > +			delta = (random() % eo->range) & -4;
> > > +			r = pread(fd, &v, sizeof(v), eo->addr + delta);
> > > +			igt_assert_eq(r, sizeof(v));
> > > +			igt_assert_eq_u32(v, 0);
> > > +
> > > +			close(fd);
> > > +		}
> > > +		priv->bind_count++;
> > > +	}
> > > +
> > > +	if (e->flags & DRM_XE_EUDEBUG_EVENT_DESTROY)
> > > +		priv->unbind_count++;
> > > +}
> > > +
> > > +static void vm_bind_clear_ack_trigger(struct xe_eudebug_debugger *d,
> > > +				      struct drm_xe_eudebug_event *e)
> > > +{
> > > +	struct drm_xe_eudebug_event_vm_bind_ufence *ef = (void *)e;
> > > +
> > > +	xe_eudebug_ack_ufence(d->fd, ef);
> > > +}
> > > +
> > > +/**
> > > + * SUBTEST: vm-bind-clear
> > > + * Description:
> > > + *      Check that fresh buffers we vm_bind into the ppGTT are always clear.
> > > + */
> > > +static void test_vm_bind_clear(int fd)
> > > +{
> > > +	struct vm_bind_clear_priv *priv;
> > > +	struct xe_eudebug_session *s;
> > > +
> > > +	priv = vm_bind_clear_priv_create();
> > > +	s = xe_eudebug_session_create(fd, vm_bind_clear_client, 0, priv);
> > > +
> > > +	xe_eudebug_debugger_add_trigger(s->debugger, DRM_XE_EUDEBUG_EVENT_VM_BIND_OP,
> > > +					vm_bind_clear_test_trigger);
> > > +	xe_eudebug_debugger_add_trigger(s->debugger, DRM_XE_EUDEBUG_EVENT_VM_BIND_UFENCE,
> > > +					vm_bind_clear_ack_trigger);
> > > +
> > > +	igt_assert_eq(xe_eudebug_debugger_attach(s->debugger, s->client), 0);
> > > +	xe_eudebug_debugger_start_worker(s->debugger);
> > > +	xe_eudebug_client_start(s->client);
> > > +
> > > +	xe_eudebug_client_wait_done(s->client);
> > > +	xe_eudebug_debugger_stop_worker(s->debugger, 1);
> > > +
> > > +	igt_assert_eq(priv->bind_count, priv->unbind_count);
> > > +	igt_assert_eq(priv->sum * 2, priv->bind_count);
> > > +
> > > +	xe_eudebug_session_destroy(s);
> > > +	vm_bind_clear_priv_destroy(priv);
> > > +}
> > > +
> 
> <cut>