[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