From: Linda Knippers <linda.knippers-VXdhtT5mjnY@public.gmane.org>
To: Alex Williamson
<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
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 10:00:41 -0400 [thread overview]
Message-ID: <553E4109.5060903@hp.com> (raw)
In-Reply-To: <1430072207.8301.103.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 4/26/2015 2:16 PM, Alex Williamson wrote:
> On Sun, 2015-04-26 at 18:55 +0100, David Woodhouse wrote:
>> On Sun, 2015-04-26 at 11:33 -0600, Alex Williamson wrote:
>>> Curious why these weren't posted to the mailing list.
>>
>> Apologies for that. I was thinking of this tree as *only* collecting
>> the stuff for SVM, and had mostly forgotten the bug-fixes. I was going
>> to post the series once I had it all in better shape... and when it
>> became apparent that SVM wasn't going to make it for 4.1 I wasn't
>> actually going to push these early parts that *are* ready at all. But
>> then I started getting badgered about the X2APIC_OPT_OUT nonsense.
>>
>>> This one in particular not only ignores RMRR on IGD, but any PCI
>>> class display device. We may understand why IGD has RMRRs, but we
>>> certainly don't understand enough to ignore RMRRs for other GPUs,
>>> should they exist.
>>
>> If they exist, they'll exist for precisely the same reason — to let
>> the graphics device continue to render its framebuffer after the IOMMU
>> is turned on.
>>
>> For a discrete card with a discrete video BIOS, as opposed to chipset
>> -integrated stuff, I suspect it's actually much *less* likely that
>> there's any other weirdness going on.
>
> Hmm, we've seen RMRRs used for health monitoring and thermal control on
> other devices. These are exactly the kinds of RMRR use cases that
> causes us trouble via the IOMMU API. GPUs are potentially the smartest
> and most power hungry peripherals in a system. I don't see how thermal
> monitoring wouldn't be an attractive target for GPUs. Are you counting
> on system vendors not having sufficient pull with the GPU vendors to
> hack into their firmware?
I can't speak for other vendors or for other use cases of RMRR but while
HP does use RMRRs for health and thermal monitoring for some devices,
we don't for GPUs.
Older releases of firmware had RMRRs for GPUs only because we had them for
all slots. Firmware since about May 2013 no longer generates them for GPUs.
A platform running old firmware may see an RMRR for a GPU but the memory
region isn't being used. I assume that GPUs have other mechanisms for
reporting health and thermal information to the platform but don't really know.
I mention this because our use of RMRR has gotten attention in the past
so I understand Alex's concern and wanted to clarify our use as it relates
to GPUs. Other vendors may be doing other things so it may still be a
valid concern. This is only a comment on the use case, not on the patch.
> I had sort of envisioned that we'd need to
> match the RMRRs to the use cases we know about for IGD to make sure
> nothing sneaks by. We should at least be documenting what the expected
> use cases are, the ranges involved, and why we can ignore them.
I think that's a good idea.
-- ljk
> Thanks,
>
> Alex
>
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2015-04-27 14:00 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 [this message]
[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
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=553E4109.5060903@hp.com \
--to=linda.knippers-vxdhtt5mjny@public.gmane.org \
--cc=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