[Intel-gfx] [PATCH RFC 2/4] drm/i915: IOMMU based SVM implementation v13

David Woodhouse dwmw2 at infradead.org
Mon Aug 15 13:04:28 UTC 2016


On Mon, 2016-08-15 at 13:53 +0100, Chris Wilson wrote:
> 
> So it is really just what happens to commands for this client when it
> dies/exits.  The kneejerk reaction is to say the pages should be kept
> alive as they are now for !svm. We could be faced with a situation where
> the client copies onto a shared buffer (obtaining a fence), passes that
> fence over to the server scheduling an update, and die abruptly.

Which pages?

Until the moment you actually do the DMA, you don't have "pages". They
might not even exist in RAM. All you have is (a PASID and) a userspace
linear address.

When you actually the DMA, *then* we might fault in the appropriate
pages from disk. Or might not, depending on whether the address is
valid or not.

Between the time when it hands you the linear address, and the time
that you use it, the process could have done anything. we are currently
talking about the case where it exits uncleanly. But it could also
munmap() the linear address in question. Or mmap() something else over
it. Obviously those would be bugs... but so is an unclean exit.

So it doesn't seem to make much sense to ask if you accept the change
in behaviour. You don't really have much choice; it's implicit in the
SVM model of doing DMA directly to userspace addresses. You just
*don't* get to lock things down and trust that the buffers will still
be there when you finally get round to using them.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20160815/9fb185b7/attachment-0001.bin>


More information about the Intel-gfx mailing list