8 Nov
2022
8 Nov
'22
2:05 a.m.
From: Jason Gunthorpe jgg@nvidia.com Sent: Monday, November 7, 2022 11:02 PM
- @allowed_iovas: Pointer to array of struct iommu_iova_range
- Ensure a range of IOVAs are always available for allocation. If this call
- succeeds then IOMMU_IOAS_IOVA_RANGES will never return a list of
IOVA ranges
- that are narrower than the ranges provided here. This call will fail if
- IOMMU_IOAS_IOVA_RANGES is currently narrower than the given
ranges.
- When an IOAS is first created the IOVA_RANGES will be maximally
sized,
and as
- devices are attached the IOVA will narrow based on the device
restrictions.
- When an allowed range is specified any narrowing will be refused, ie
device
- attachment can fail if the device requires limiting within the allowed
range.
- Automatic IOVA allocation is also impacted by this call. MAP will only
- allocate within the allowed IOVAs if they are present.
According to iopt_check_iova() FIXED_IOVA can specify an iova which is not in allowed list but in the list of reported IOVA_RANGES. Is it correct or make more sense to have FIXED_IOVA also under guard of the allowed list (if violating then fail the map call)?
The concept was the allow list only really impacts domain attachment. When a user uses FIXED they have to know what they are
it also impacts automatic IOVA
doing. There is not a good reason to deny the user to use any IOVA that is not restricted by the reserved list.
I just didn't get why different restrictions are applied to automatics vs. fixed allocation.