From: Alex Williamson <alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org
Subject: Re: [GIT PULL] Intel IOMMU for 4.1
Date: Mon, 27 Apr 2015 11:30:52 -0600 [thread overview]
Message-ID: <1430155852.4472.85.camel@redhat.com> (raw)
In-Reply-To: <1430154752.6377.19.camel-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
On Mon, 2015-04-27 at 18:12 +0100, David Woodhouse wrote:
> On Mon, 2015-04-27 at 09:39 -0600, Alex Williamson wrote:
> > David,
> >
> > Since this got pulled anyway, do you plan to follow-up with patches to
> > limit the graphics RMRR exception to the known and acceptable uses and
> > document them, or should I send a revert patch? I don't think what we
> > have here is acceptable going forward or being backported to stable.
> > Thanks,
>
> I didn't plan to, no. So far we *only* know of acceptable uses of RMRR
> on graphics devices, and the false positives that Linda mentioned.
>
> The only cases we ever saw of RMRR being *problematic* when we tried
> to assign devices to guests were non-graphics devices, weren't they?
That's true, but if we're only trying to enable IGD assignment (which of
course doesn't work yet anyway), why add the entire PCI class rather
than perhaps at least testing for vendor ID 8086 and pci_is_root_bus()?
I don't see why we want to open the door any wider than necessary.
> Although obviously I'm looking into the oops that sl4ever reported;
> currently I'm wondering if that was broken even before your patch that
> blacklisted all RMRR-afflicted devices. It looks like
> device_to_iommu() doesn't return the correct results for devices
> behind a disabled IOMMU; it incorrectly attributes them to a catch-all
> IOMMU instead.
>
> Or perhaps this is probably tied into the fact that your patch broke
> iommu=pt for RMRR-afflicted devices too. They currently get full
> translation. Which surely shouldn't be necessary, since passthrough
> mode would obviously *also* preserve the RMRR regions of 1:1 mappings.
I think you're actually referring to:
commit ea2447f700cab264019b52e2b417d689e052dcfd
Author: Tom Mingarelli <thomas.mingarelli-VXdhtT5mjnY@public.gmane.org>
Date: Tue Nov 20 19:43:17 2012 +0000
intel-iommu: Prevent devices with RMRRs from being placed into SI Domain
This patch is to prevent non-USB devices that have RMRRs associated with the
being placed into the SI Domain during init. This fixes the issue where the
for devices being placed in and out of the SI Domain gets lost.
Signed-off-by: Thomas Mingarelli <thomas.mingarelli-VXdhtT5mjnY@public.gmane.org>
Tested-by: Shuah Khan <shuah.khan-VXdhtT5mjnY@public.gmane.org>
Reviewed-by: Donald Dutile <ddutile-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Reviewed-by: Alex Williamson <alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
That patch has been present since v3.8 and was only cosmetically
affected by my patch with a shared helper function. Thanks,
Alex
prev parent reply other threads:[~2015-04-27 17:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-26 8:51 [GIT PULL] Intel IOMMU for 4.1 David Woodhouse
[not found] ` <1430038266.4833.14.camel-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2015-04-26 17:33 ` Alex Williamson
[not found] ` <1430069591.8301.91.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-04-26 17:55 ` David Woodhouse
[not found] ` <1430070924.13479.5.camel-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2015-04-26 18:16 ` Alex Williamson
[not found] ` <1430072207.8301.103.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-04-27 14:00 ` Linda Knippers
[not found] ` <553E4109.5060903-VXdhtT5mjnY@public.gmane.org>
2015-04-27 15:39 ` Alex Williamson
[not found] ` <1430149195.4472.43.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-04-27 15:48 ` Linus Torvalds
[not found] ` <CA+55aFx+QhMZpCtnG2sHib+kk5BR+PeEa99-CCushSA5oAqVxw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-04-27 16:09 ` Linda Knippers
2015-04-27 16:16 ` Alex Williamson
2015-04-27 17:28 ` David Woodhouse
2015-04-27 17:12 ` David Woodhouse
[not found] ` <1430154752.6377.19.camel-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2015-04-27 17:30 ` Alex Williamson [this message]
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=1430155852.4472.85.camel@redhat.com \
--to=alex.williamson-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=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