Re: [Intel-gfx] [PATCH v2] iommu/intel: Exclude devices using RMRRs from IOMMU API domains

From: Daniel Vetter
Date: Tue Jun 17 2014 - 03:15:33 EST


On Tue, Jun 17, 2014 at 9:04 AM, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
> On Mon, 2014-06-16 at 23:35 -0600, Alex Williamson wrote:
>>
>> Any idea what an off-the-shelf Asus motherboard would be doing with an
>> RMRR on the Intel HD graphics?
>>
>> dmar: RMRR base: 0x000000bb800000 end: 0x000000bf9fffff
>> IOMMU: Setting identity map for device 0000:00:02.0 [0xbb800000 - 0xbf9fffff]
>
> Hm, we should have thought of that sooner. That's quite normal â it's
> for the 'stolen' memory used for the framebuffer. And maybe also the
> GTT, and shadow GTT and other things; I forget precisely what, and it
> varies from one setup to another.
>
> I'd expect fairly much all systems to have an RMRR for the integrated
> graphics device if they have one, and your patch is going to prevent
> assignment of those to guests... as you've presumably noticed.
>
> I'm not sure if the i915 driver is capable of fully reprogramming the
> hardware to completely stop using that region, to allow assignment to a
> guest with a 'pure' memory map and no stolen region. I suppose it must,
> if assignment to guests was working correctly before?
>
> Perhaps the better answer here is not to have the special cases in
> 'device_is_rmrr_locked()', and instead allow a device driver to call a
> 'iommu_release_rmrrs()' function once it's reset the hardware to *stop*
> doing whatever DMA the BIOS set it up with.

We've always been struggling with stolen handling, and we've' always
been struggling with vt-d stuff. Also pass-through seems to be a major
pain (I've never tried myself). Given all that I'm voting for keeping
the RMRR and everything else as much like for the normal case since I
have no idea what exactly must be remapped and what's optional. The
gpu is definitely keeping a lot of it's own private stuff in various
chunks of stolen memory.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/