[Intel-gfx] [PATCH v2 for -fixes] drm/i915: Disable stolen memory when DMAR is active

[David Woodhouse]

On Thu, 2014-03-20 at 10:45 +0100, Daniel Vetter wrote:
> I'd agree that this would be nice, but my maintainer time is not
> endless and when I have users screaming "regression" I do have to do
> something. And yeah with the track record set of some of the earliest
> vtd+gfx chips I'm fairly aggressive with just disabling features,

It's not just the earlier vtd+gfx chips. To my knowledge we've *never*
shipped a chip without egregious hardware bugs with VT-d.

> especially when the original bug report is against a recent platform
> like ivb (so presumably issues on olders exist, too).

Yes, by all means disable it for current and old chipsets. But please
not newer ones. I want it to show up when the validation folks use Linux
to test the hardware. And if we *do* have to subsequently bump the check
to include the next revision of the hardware, I want someone's head on a
plate.

As I commented in private, this is the first time we've used
intel_iommu_gfx_mapped to disable a feature without a check for specific
hardware revisions. Please don't do that.

> Now this very likely is some fumble in our code, after all the bios
> managed to set things up.

Maybe not; sometimes it's just that Linux does a little bit more with
the hardware and happens to tickle the bug. The superpage screwup I've
recently been chasing, for example, is blatantly a hardware issue but
didn't show up with the BIOS framebuffer. And *does* with the Linux
framebuffer in stolen memory.

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20140320/d50e1f8c/attachment.bin>