Hi Alex, > -----Original Message----- > From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx] > Sent: 08 June 2018 03:56 > To: Alex Williamson <alex.williamson@xxxxxxxxxx> > Cc: dwmw2@xxxxxxxxxxxxx; iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx; > kvm@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Shameerali Kolothum > Thodi <shameerali.kolothum.thodi@xxxxxxxxxx> > Subject: RE: [RFC PATCH] iommu/vt-d: Exclude known RMRRs from reserved > ranges > > > 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... Sorry, but I just thought of checking on the future plans/directions for solving this issue(Unfortunately vfio iova list series depends on this). Please let me know if there is any plans for a v2 soon. Much appreciated, Shameer
