HP may have been shipping such things 'for a while' but it's never actually worked right, yes? This thread is about the patch that's intended to *fix* that?
If they could just manage to make their firmware-owned DMA appear to be from a different PCIe device/function from the one the OS gets to own, that would make things "just work", right? Hell, their laptops already have Ricoh multi-function devices that do their DMA from the 'wrong' function.... take that concept and make it useful... If the DMA could be hidden from the IOMMU altogether, all the better. But at least coming from its own dedicated devfn would avoid the issues this patch attempts to solve. -- dwmw2 (Apologies for HTML and top-posting; Android mailer is broken.)Alex Williamson <[email protected]> wrote: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
