I still think you're overstretching the IOMMU reserved region interface
by trying to report possible ACS conflicts. Are we going to update the
reserved list on device hotplug? Are we going to update the list when
MMIO is enabled or disabled for each device? What if the BARs are
reprogrammed or bridge apertures changed? IMO, the IOMMU reserved list
should account for specific IOVA exclusions that apply to transactions
that actually reach the IOMMU, not aliasing that might occur in the
downstream topology. Additionally, the IOMMU group composition must be
such that these sorts of aliasing issues can only occur within an IOMMU
group. If a transaction can be affected by the MMIO programming of
another group, then the groups are drawn incorrectly for the isolation
capabilities of the hardware. Thanks,
Agree that this is not a perfect thing to do covering all scenarios. As Robin
pointed out, the current code is playing safe by reserving the full windows.
My suggestion will be to limit this reservation to non-ACS cases only. This will
make sure that ACS ARM hardware is not broken by this series and nos-ACS
ones has a chance to run once Qemu is updated to take care of the reserved
regions (at least in some user scenarios).
If you all are fine with this, I can include the ACS check I mentioned earlier in
iommu_dma_get_resv_regions() and sent out the revised series.
Please let me know your thoughts.
IMO, the IOMMU should be concerned with ACS as far as isolation is
concerned and reporting reserved ranges that are imposed at the IOMMU
and leave any aliasing or routing issues in the downstream topology to
other layers, or perhaps to the user. Unfortunately, enforcing the
iova list in vfio is gated by some movement here since we can't break
existing users. Thanks,