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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1403188160.3707.242.camel@ul30vt.home>
Date:	Thu, 19 Jun 2014 08:29:20 -0600
From:	Alex Williamson <alex.williamson@...hat.com>
To:	Daniel Vetter <daniel@...ll.ch>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	iommu@...ts.linux-foundation.org, chegu_vinod@...com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Intel Graphics Development <intel-gfx@...ts.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v2] iommu/intel: Exclude devices using RMRRs
 from IOMMU API domains

On Thu, 2014-06-19 at 08:10 +0200, Daniel Vetter wrote:
> On Thu, Jun 19, 2014 at 3:47 AM, Alex Williamson
> <alex.williamson@...hat.com> wrote:
> > Finding some more specs... the MGGC0 register (50h) seems to indicate
> > the GTT stolen memory size is 2M, which sounds suspiciously like the 2M
> > that the RMRR is reporting.  However, from the IvyBridge MMIO, Media
> > Registers & Programming Env manual:
> >
> >         4.6.1 Changes to GTT
> >
> >         The GTT is constrained to be located at the beginning of a
> >         special section of stolen memory called the GTT stolen memory
> >         (GSM). There is no longer an MMIO register containing the
> >         physical base address of the GTT as on prior devices. Instead of
> >         using the PGTBL_CTL register to specify the base address of the
> >         GTT, the GTT base is now defined to be at the bottom (offset 0)
> >         of GSM.
> >
> >         Since the graphics device (including the driver) knows nothing
> >         about the location of GSM, it does not “know” where the GTT is
> >         located in memory. In fact, the CPU cannot directly access the
> >         GSM containing the GTT.
> >
> > That seems to suggest we can't discover this region from the device, but
> > the device does need to maintain access to it... I don't know how to
> > resolve that without exposing the RMRR through the IOMMU API.
> >
> > In any case, I don't know that any of this should block the original
> > patch.  All of this seems like "acceptable" use of RMRRs that we can
> > later add an exception to allow if we get to the point of understanding
> > it and being able to reproduce any required mappings in the guest.
> > Thanks,
> 
> GTT stolen is the place where the gpu stores page tables. We never
> access them directly but through a special mmio range so that the gpu
> can intercept pte updates and invalidate tlbs accordingly. So yeah, we
> need this, too.

But is there a way for software to discover its location from the
device?  If so, then I think we can recreate all the identity maps we'd
need for a guest from the device.  If not, then we'd need to figure out
some IOMMU API extension to handle the mapping.  The spec excerpt above
seems to indicate that hardware designers decided software doesn't need
to know about it, but the RMRR seems to be the "oh crap" moment when
they realized that yes we do need to know about it.  Thanks,

Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/