[Intel-gfx] [PATCHi v2] drm/i915: Enhanced disable access to stolen memory as a guest

Daniel Vetter daniel at ffwll.ch
Wed Mar 29 11:58:49 UTC 2017


On Tue, Mar 28, 2017 at 01:28:43AM +0000, Zhang, Xiong Y wrote:
> > > Reviewed-by: Zhenyu Wang <zhenyuw at linux.intel.com>
> > 
> > Entirely disabling stolen is rather massive, this stuff is supposed to
> > work ... There should be special RMRR mappings in the iommu to help the
> > guest access the stolen range correctly from the gpu.
> > 
> > Which machine where does this blow up on?
> > -Daniel
> [Zhang, Xiong Y] Yes. Stolen memory is protected by RMRR on host. But Qemu couldn't support and don't have plan to support RMRR. Then EPT lack of mapping for stolen memory, guest couldn't access it.
> The Qemu/Vfio is designed by Redhat engineers, Redhat has a white paper to explain why Qemu don't support RMRR:
> https://access.redhat.com/sites/default/files/attachments/rmrr-wp1.pdf

I chatted with Joonas, and he dug out the commit that changed this:

commit c875d2c1b8083cd627ea0463e20bf22c2d7421ee
Author: Alex Williamson <alex.williamson at redhat.com>
Date:   Thu Jul 3 09:57:02 2014 -0600

    iommu/vt-d: Exclude devices using RMRRs from IOMMU API domains
    
    The user of the IOMMU API domain expects to have full control of
    the IOVA space for the domain.  RMRRs are fundamentally incompatible
    with that idea.  We can neither map the RMRR into the IOMMU API
    domain, nor can we guarantee that the device won't continue DMA with
    the area described by the RMRR as part of the new domain.  Therefore
    we must prevent such devices from being used by the IOMMU API.
    
    Signed-off-by: Alex Williamson <alex.williamson at redhat.com>
    Cc: David Woodhouse <dwmw2 at infradead.org>
    Cc: stable at vger.kernel.org
    Signed-off-by: Joerg Roedel <jroedel at suse.de>

Please reference that commit (plus the whitepaper if you want to) in your
commit message, and resubmit it with a Fixes: and cc: stable lines. This
sounds like a bugfix that we need to backport.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list