On Fri, 2012-09-28 at 14:52 +0200, Joerg Roedel wrote: > On Fri, Sep 28, 2012 at 06:40:08AM -0600, Alex Williamson wrote: > > On Fri, 2012-09-28 at 11:43 +0200, Joerg Roedel wrote: > > > > I don't think so. The concept of RMRR is just not defined well enough > > > (like the concept of unity mappings on the AMD side which is similar to > > > RMRR). The definition says, that any memory region must be mapped at > > > any time for the device. But that is not true (at least I have no > > > counter-example yet). The right definition would be, that the RMRR > > > regions are only necessary as long as the operating system does not > > > control the particular device. And assigning a device to a guest also > > > counts a 'taking control over the device'. > > > > I think HP folks would be very unhappy with that definition. As David > > indicates, that's how things like USB use RMRR, but the actual > > definition in the spec leaves much more room for abuse. Thanks, > > To my experience, for a hardware designer, existing software overrides > any Spec because it is much worse to break existing software than it is > to break a Spec :) So, unless we break existing hardware/firmware, I > still suggest that we use the assumption that OS controlled devices do > not need RMRR/unity-mapped regions anymore.
HP has been shipping hardware that makes use of RMRRs for other purposes for a while. > Is HP doing anything in their firmware which would not work with that? Yes, I'll let them fill in the details. > For the USB controlers, they only generate DMA to the RMRR/unity-mapped > region until the OS takes over control from the firmware. After > the USB driver is initialized the RMRR region should not be necessary > anymore. I agree that was probably the intent, but vendors have found loopholes as their opportunity to innovate. Thanks, Alex _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
