From: Jason Gunthorpe jgg@nvidia.com Sent: Tuesday, December 12, 2023 10:40 PM
On Tue, Dec 12, 2023 at 01:45:16PM +0000, Liu, Yi L wrote:
From: Jason Gunthorpe jgg@nvidia.com Sent: Monday, December 11, 2023 9:22 PM
On Mon, Dec 11, 2023 at 03:53:40PM +0800, Yi Liu wrote:
From that thread Jason mentioned to make the invalidation format part of domain allocation. If that is the direction to go then there won't be multiple invalidation formats per hwpt. The user should create multiple hwpt's per invalidation format (though mixing formats in one virtual platform is very unlikely)?
I think we could do either, but I have a vauge cleanness preference that the enums are just different? That would follow a pretty typical pattern for a structure tag to reflect the content of the structure.
Is this still following the direction to make the invalidation format part of domain allocation?
I think you should make it seperate
Sure. I'll add a separate enum for cache invalidation format. Just to see if it is good to pass down the invalidation format in the hwpt alloc path? So iommu driver can check if the invalidation format can be used for the hwpt to be allocated.
I would skip it in the invalidation. If necessary drivers can push a 0 length invalidation to do 'try and fail' discovery of supported types.
I think you mean keep passing the req_type in cache invalidation path instead of the way I proposed. For the 'try and fail' discovery, we should allow a zero-length array, is it? If the req_type is supported by the iommu driver, then return successful, otherwise fail the ioctl. Is it?
Regards, Yi Liu