On 18/01/2023 19:40, Alex Williamson wrote:
On Wed, 18 Jan 2023 11:15:07 -0400
Jason Gunthorpe <jgg@xxxxxxxxxx> wrote:
On Tue, Jan 17, 2023 at 04:38:11PM -0700, Alex Williamson wrote:
The type1 IOMMU backend is notably absent here among the core files, any
reason?
Mostly fear that charging alot of memory to the cgroup will become a
compatibility problem. I'd be happier if we go along the iommufd path
some more and get some field results from cgroup enablement before we
think about tackling type 1.
With this series in normal non-abusive cases this is probably only a
few pages of ram so it shouldn't be a problem. mlx5 needs huge amounts
of memory but it is new so anyone deploying a new mlx5 configuration
can set their cgroup accordingly.
If we fully do type 1 we are looking at alot of memory. eg a 1TB
guest will charge 2GB just in IOPTE structures at 4k page size. Maybe
that is enough to be a problem, I don't know.
Potentially this removes the dma_avail issue as a means to
prevent userspace from creating an arbitrarily large number of DMA
mappings, right?
Yes, it is what iommufd did
Are there any compatibility issues we should expect with this change to
accounting otherwise?
Other than things might start hitting the limit, I don't think so?
Ok, seems like enough FUD to limit the scope for now. We'll need to
monitor this for native and compat mode iommufd use. I'll fix the
commit log typo, assuming there are no further comments. Thanks,
Alex
Alex,
Based on the above, can you please take it into your next branch ?
I would like to send soon some small series in mlx5 driver which
improves some flows as part of pre_copy to reduce downtime as part of
stop_copy.
Some code there should be sent on top of current series.
Thanks,
Yishai
