Re: [PATCH 6/9] drm/i915: driver based PASID handling

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1561 bytes --]

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@intel.com                              Intel Corporation


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx