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

Manszewski, Christoph christoph.manszewski at intel.com
Tue Sep 17 16:00:51 UTC 2024


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.

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>


More information about the igt-dev mailing list