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

David Woodhouse dwmw2 at infradead.org
Fri Oct 9 00:56:24 PDT 2015


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?

> 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 :)

-- 
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/f9289c8b/attachment-0001.bin>


More information about the Intel-gfx mailing list