On Thu, 2012-09-27 at 15:34 -0600, Alex Williamson wrote:
> It really seems like RMRRs are incompatible with IOMMU API use though.
> If an RMRR is setup for a VM domain, that's bad because a) it gives the
> VM direct access to that range of host memory, and b) it interferes with
> the guest use of the address space.  a) is also bad for isolating
> devices on the host, but the spec makes it available for abuse.  For b),
> it's not hard to imagine an RMRR range on the host that overlaps with
> DMA'able space on the guest.  Data is read or written to the host memory
> instead of the guest memory.  So maybe the right answer is to make
> intel_iommu_attach_device return error if requested to act on a device
> with RMRR ranges.

That would include fairly much any USB host controller. The whole RMRR
concept is completely broken and should never have been invented. The
idea that firmware-controlled DMA should continue to happen *after* the
operating system has been booted and taken control of the hardware is
just insane.

The majority of RMRR use is for USB controllers, so that firmware can
emulate a legacy keyboard for the benefit of pre-USB operating systems.
But no operating system that old is ever going to support the IOMMU
anyway, so that's just mad. But that's why we've managed to get away
with setting up the RMRRs and then tearing them down when a native
driver has actually taken control of the hardware — because at that
point, it should have been reset and whatever the firmware had
configured to do has been abandoned.

Perhaps we should have a special case for USB controllers, which are
quite happy when you drop their RMRR regions when the OS takes over, and
for any *other* device with RMRRs, have a TAINT_YOUR_FIRMWARE_IS_INSANE
and just refuse to let a native driver do anything at all with them?

-- 
dwmw2