On Mon, Nov 14, 2022 at 10:21:50AM -0500, Matthew Rosato wrote:
> On 11/14/22 9:59 AM, Jason Gunthorpe wrote:
> > On Mon, Nov 14, 2022 at 09:55:21AM -0500, Matthew Rosato wrote:
> >>>> AFAICT there is no equivalent means to specify
> >>>> vfio_iommu_type1.dma_entry_limit when using iommufd; looks like
> >>>> we'll just always get the default 65535.
> >>>
> >>> No, there is no arbitary limit on iommufd
> >>
> >> Yeah, that's what I suspected. But FWIW, userspace checks the
> >> advertised limit via VFIO_IOMMU_GET_INFO /
> >> VFIO_IOMMU_TYPE1_INFO_DMA_AVAIL, and this is still being advertised
> >> as 65535 when using iommufd. I don't think there is a defined way
> >> to return 'ignore this value'.
> >
> > Is something using this? Should we make it much bigger?
>
> Yes, s390 when doing lazy unmapping likes to use larger amounts of
> concurrent DMA, so there can be cases where we want to raise this
> limit.
>
> The initial value of 65535 is already pretty arbitrary (U16_MAX) --
It was choosen to match VFIO's default
> If iommufd is doing its own management and this value becomes
> deprecated in this scenario, and we can't set it to a magic value
> that says 'ignore me' then maybe it just makes sense for now to set
> it arbitrarily larger when using iommufd e.g. U32_MAX?
Sure
/*
* iommufd's limit is based on the cgroup's memory limit.
* Normally vfio would return U16_MAX here, and provide a module
* parameter to adjust it. Since S390 qemu userspace actually
* pays attention and needs a value bigger than U16_MAX return
* U32_MAX.
*/
.avail = U32_MAX,
Thanks,
Jason
