On Tue, Jul 12, 2016 at 11:50:26AM +0300, Joonas Lahtinen wrote:
> On pe, 2016-06-24 at 14:07 +0100, Chris Wilson wrote:
> > One of the numerous VT-d workarounds we require is that the display
> > hardware reads past the end of the buffer triggering VT-d faults. This
> > is acknowledged in the code
On pe, 2016-06-24 at 14:07 +0100, Chris Wilson wrote:
> One of the numerous VT-d workarounds we require is that the display
> hardware reads past the end of the buffer triggering VT-d faults. This
> is acknowledged in the code as being safe "since we fill the unused
> portions of the GGTT with the
On Fri, Jul 08, 2016 at 03:29:30PM +0300, David Weinehall wrote:
> On Fri, Jun 24, 2016 at 02:07:14PM +0100, Chris Wilson wrote:
> > One of the numerous VT-d workarounds we require is that the display
> > hardware reads past the end of the buffer triggering VT-d faults. This
> > is acknowledged in
On Fri, Jun 24, 2016 at 02:07:14PM +0100, Chris Wilson wrote:
> One of the numerous VT-d workarounds we require is that the display
> hardware reads past the end of the buffer triggering VT-d faults. This
> is acknowledged in the code as being safe "since we fill the unused
> portions of the GGTT w
On Fri, Jun 24, 2016 at 02:07:14PM +0100, Chris Wilson wrote:
> One of the numerous VT-d workarounds we require is that the display
> hardware reads past the end of the buffer triggering VT-d faults. This
> is acknowledged in the code as being safe "since we fill the unused
> portions of the GGTT w
One of the numerous VT-d workarounds we require is that the display
hardware reads past the end of the buffer triggering VT-d faults. This
is acknowledged in the code as being safe "since we fill the unused
portions of the GGTT with the scratch page". Alas, that is no longer
always true and so we t
