Re: [GIT PULL] Intel IOMMU for 4.1

[Alex Williamson <alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On Mon, 2015-04-27 at 10:00 -0400, Linda Knippers wrote:
> 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.

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,

Alex

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu