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 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. Thanks, Alex _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
