[Intel-gfx] [PATCH 6/9] drm/i915: driver based PASID handling

Daniel Vetter daniel at ffwll.ch
Fri Oct 9 01:47:47 PDT 2015


On Fri, Oct 09, 2015 at 08:56:24AM +0100, David Woodhouse wrote:
> On Fri, 2015-10-09 at 09:28 +0200, Daniel Vetter wrote:
> > 
> > Hm if this still works the same way as on older platforms then pagefaults
> > just read all 0 and writes go nowhere from the gpu. That generally also
> > explains ever-increasing numbers of the CS execution pointer since it's
> > busy churning through 48b worth of address space filled with MI_NOP. I'd
> > have hoped our hw would do better than that with svm ...
> 
> I'm looking at simple cases like Jesse's 'gem_svm_fault' test. If the
> access to process address space (a single dword write) does nothing,
> I'm not sure why it would then churn through MI_NOOPs; why would the
> batch still not complete?

Yeah that testcase doesn't fit, the one I had in mind is where the batch
itself faults and the CS just reads MI_NOP forever. No idea why the gpu
just keeps walking through the address space here. Puzzling.

> > If there's really no way to make it hang when we complete the fault then I
> > guess we'll have to hang it by not completing. Otherwise we'll have to
> > roll our own fault detection code right from the start.
> 
> Well, theoretically there are ways we could handle this. It looks like
> if I *don't* give the IOMMU a response to the page request, the context
> remains hung and waiting for it. So I could give you a callback,
> including the 'private' data from the page request that we know
> identifies the context. So perhaps we *could* contrive to give you
> precise exceptions when the hardware doesn't really do that sanely.
> 
> But I was really trying hard to avoid the necessity for that kind of
> hack to work around stupid hardware :)

I'll take a look at your latest series. But yeah we might need that
callback to update resets/ctx-is-toast stats on our side if the gpu
doesn't naturally fall over if there's no memory.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list