From: Alex Williamson <alex.williamson@redhat.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: chegu_vinod@hp.com, iommu@lists.linux-foundation.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH v2] iommu/intel: Exclude devices using RMRRs from IOMMU API domains
Date: Thu, 19 Jun 2014 08:29:20 -0600 [thread overview]
Message-ID: <1403188160.3707.242.camel@ul30vt.home> (raw)
In-Reply-To: <CAKMK7uE6Ab7pvyNvz7sd7QD1ZKDXd6kkEmXHxTzeFCmH1Z_bMQ@mail.gmail.com>
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@redhat.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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2014-06-19 14:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-13 16:30 [PATCH v2] iommu/intel: Exclude devices using RMRRs from IOMMU API domains Alex Williamson
[not found] ` <20140613162901.4550.94476.stgit-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2014-06-17 5:35 ` Alex Williamson
2014-06-17 7:04 ` David Woodhouse
2014-06-17 7:15 ` Daniel Vetter
2014-06-17 7:21 ` David Woodhouse
2014-06-17 8:14 ` [Intel-gfx] " Daniel Vetter
2014-06-17 12:22 ` Alex Williamson
2014-06-17 12:41 ` David Woodhouse
2014-06-17 13:16 ` Alex Williamson
2014-06-17 13:44 ` Daniel Vetter
2014-06-17 14:15 ` Alex Williamson
2014-06-17 16:45 ` Daniel Vetter
2014-06-17 16:59 ` Alex Williamson
2014-06-17 17:53 ` Daniel Vetter
2014-06-18 21:48 ` Alex Williamson
2014-06-19 1:47 ` Alex Williamson
2014-06-19 6:10 ` Daniel Vetter
2014-06-19 14:29 ` Alex Williamson [this message]
2014-06-19 14:41 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1403188160.3707.242.camel@ul30vt.home \
--to=alex.williamson@redhat.com \
--cc=chegu_vinod@hp.com \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox