KFD event handling questions

[Jay Cornwall]

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.