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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
