[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