Yes, should be okay to disable debugger tests as we don't support old debugger post-1.5 release. I've sent an email to Tools team and cc'd so we give them a heads-up. As Jay said, we're actively working on the new debugger design and don't have a need for hard-coding special event IDs anymore. Thanks Hari -----Original Message----- From: Jay Cornwall [mailto:jay@xxxxxxxxxxxxx] Sent: Monday, October 2, 2017 10:05 AM To: Kuehling, Felix <Felix.Kuehling at amd.com>; Thangirala, Hari <Hari.Thangirala at amd.com>; amd-gfx at lists.freedesktop.org; Oded Gabbay <oded.gabbay at gmail.com> Subject: Re: KFD event handling questions On Mon, Oct 2, 2017, at 08:22, Kuehling, Felix wrote: > Is the "new debug trap handler" already working? It seems right now > I'm breaking the "old" debugger backend test. However, given the > current status of that debugger, I guess we can disable those tests for now? > > Can you speak on behalf of the debugger team, or should I consult > someone else on their end as well? The existing debug API was designed to interact with live wavefronts on the device. This created problems for the scheduler, which needs to be able to remove wavefronts at any time without notice. The unprivileged debugger could interfere with privileged operations (e.g. debugging in the presence of oversubscribed processes, world switch in SR-IOV). It wasn't developed beyond internal test cases and the ioctls should not have been upstreamed. The debugger was redesigned to work with offline wavefront state collected through wavefront context save (already implemented in the scheduler and controlled through hsaKmtUpdateQueue). This respects the privilege model and is robust in all scheduling scenarios. There are stil some yet-to-be-determined interfaces to control per-process debugging features. This could extend/repurpose an existing ioctl or require a new one.
