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

David Woodhouse dwmw2 at infradead.org
Fri Oct 9 02:07:21 PDT 2015

On Fri, 2015-10-09 at 10:47 +0200, Daniel Vetter wrote:
> 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.

Does it just keep walking through the address space?

When I hacked my page request handler to *not* service the fault and
just say it failed, the batch did seem to complete as normal. Just
without doing the write, as you described.

David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20151009/20f8c56e/attachment-0001.bin>

More information about the Intel-gfx mailing list