[Intel-gfx] [PATCH] drm/i915/vlv: Added write-enable pte bit support

[Goel, Akash]

>> What happens when we GTT-mapped write a batchbuffer that had previously been silently made RO by the kernel?  Does the CPU take a fault?
We tested this particular case, doing the relocation inside the Batch buffer, which is mapped to GTT as read-only, from the exec-buffer path.
On doing so, there were no faults observed on the CPU side.
 
Also we don't see any ring hangs, when forcing the GPU to do a write access on the buffers marked as RO. Just the writes were getting rejected.
 
Best Regards
Akash
-----Original Message-----
From: Eric Anholt [mailto:eric at anholt.net] 
Sent: Friday, February 07, 2014 3:11 AM
To: Goel, Akash; intel-gfx at lists.freedesktop.org
Cc: Goel, Akash
Subject: Re: [Intel-gfx] [PATCH] drm/i915/vlv: Added write-enable pte bit support

akash.goel at intel.com writes:

> From: Akash Goel <akash.goel at intel.com>
>
> This adds support for using the write-enable bit in the GTT entry for VLV.
> This is handled via a read-only flag in the GEM buffer object which is 
> then used to check if the write-enable bit has to be set or not when 
> writing the GTT entries.
> Currently by default only the Batch buffer & Ring buffers are being 
> marked as read only.

What happens when we GTT-mapped write a batchbuffer that had previously been silently made RO by the kernel?  Does the CPU take a fault?