RE: [RFC PATCH] iommu/vt-d: Exclude known RMRRs from reserved ranges

[Tian, Kevin]

> From: Alex Williamson [mailto:alex.williamson@xxxxxxxxxx]
> Sent: Thursday, June 7, 2018 11:02 PM
> 
> On Wed, 6 Jun 2018 05:29:58 +0000
> "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
> 
> > > From: Alex Williamson
> > > Sent: Wednesday, June 6, 2018 3:07 AM
> > >
> > > device_is_rmrr_locked() allows graphics and USB devices to participate
> > > in the IOMMU API despite, and ignoring their RMRR association,
> however
> > > intel_iommu_get_resv_regions() still includes the RMRRs as unavailable
> > > IOVA space for the device.  Are we ignoring the RMRR for these devices
> > > or are we not?  If vfio starts consuming reserved regions, perhaps we
> > > no longer need to consider devices with RMRRs excluded from the
> IOMMU
> > > API interface, but we have a transitional problem that these allowed
> > > devices still impose incompatible IOVA restrictions per the reserved
> > > region reporting.  Dive further down the rabbit hole by also ignoring
> > > RMRRs for "known" devices in the reserved region reporting.
> >
> > intel_iommu_get_resv_regions is used not just for IOMMU API. I'm
> > afraid doing so will make RMRR completely ignored, even in normal
> > DMA API path...
> 
> Well, I'm a bit stuck then, we have existing IOMMU API users that
> ignore these ranges and in fact conflict with these ranges blocking us
> from restricting mappings within these ranges.  My impression is that
> IOMMU reserved ranges should only be ranges which have some
> fundamental
> limitation in the IOMMU, not simply mappings for which firmware has
> requested an identity mapped range.  The latter should simply be a
> pre-allocation of the IOVA space, for the cases where we choose to
> honor the RMRR.  Thanks,
> 

Then possibly need introduce a different interface for pre-allocation
scenario, if above definition of reserved ranges is agreed. Currently
two categories are both called reserved resources, e.g. IOMMU_RESV
_DIRECT for rmrr and IOMMU_RESV_MSI for MSI...

Thanks
Kevin