Re: [PATCH v2] Intel IOMMU patch to reprocess RMRR info

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

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