From: David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
To: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Subject: [GIT PULL] VT-d hardware workarounds for 4.1
Date: Fri, 12 Jun 2015 12:06:35 +0100 [thread overview]
Message-ID: <1434107195.13776.32.camel@infradead.org> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 1838 bytes --]
Linus, please pull, again, from
git://git.infradead.org/intel-iommu.git
This contains a workaround for hardware issues which I *thought* were
never going to be seen on production hardware. I'm glad I checked that
before the 4.1 release...
Firstly, PASID support is so broken on existing chips that we're just
going to declare the old capability bit 28 as 'reserved' and change the
VT-d spec to move PASID support to another bit. So any existing
hardware doesn't support SVM; it only sets that (now) meaningless bit
28.
That patch *wasn't* imperative for 4.1 because we don't have PASID
support yet. But *even* the extended context tables are broken — if you
just enable the wider tables and use none of the new bits in them,
which is precisely what 4.1 does, you find that translations don't
work. It's this problem which I thought was caught in time to be fixed
before production, but wasn't.
To avoid triggering this issue, we now *only* enable the extended
context tables on hardware which also advertises "we have PASID support
and we actually tested it this time" with the new PASID feature bit.
In addition, I've added an 'intel_iommu=ecs_off' command line parameter
to allow us to disable it manually if we need to.
David Woodhouse (2):
iommu/vt-d: Change PASID support to bit 40 of Extended Capability Register
iommu/vt-d: Only enable extended context tables if PASID is supported
Documentation/kernel-parameters.txt | 6 ++++++
drivers/iommu/intel-iommu.c | 18 +++++++++++++++---
include/linux/intel-iommu.h | 3 ++-
3 files changed, 23 insertions(+), 4 deletions(-)
--
David Woodhouse Open Source Technology Centre
David.Woodhouse-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org Intel Corporation
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
reply other threads:[~2015-06-12 11:06 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1434107195.13776.32.camel@infradead.org \
--to=dwmw2-wegcikhe2lqwvfeawa7xhq@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.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