On 2024/9/9 21:40, Jason Gunthorpe wrote:
On Mon, Sep 09, 2024 at 09:29:09PM +0800, Yi Liu wrote:
On 2024/9/9 21:04, Jason Gunthorpe wrote:
On Mon, Sep 09, 2024 at 08:59:32PM +0800, Yi Liu wrote:
In order to synthesize the vPASID cap, the VMM should get to know the
capabilities like Privilege mode, Execute permission from the physical
device's config space. We have two choices as well. vfio or iommufd.
It appears to be better reporting the capabilities via vfio uapi (e.g.
VFIO_DEVICE_FEATURE). If we want to go through iommufd, then we need to
add a pair of data_uptr/data_size fields in the GET_HW_INFO to report the
PASID capabilities to userspace. Please let me know your preference. :)
I don't think you'd need a new data_uptr, that doesn't quite make
sense
What struct data do you imagine needing?
something like below.
struct iommufd_hw_info_pasid {
__u16 capabilities;
#define IOMMUFD_PASID_CAP_EXEC (1 << 0)
#define IOMMUFD_PASID_CAP_PRIV (1 << 1)
__u8 width;
__u8 __reserved;
};
I think you could just stick that in the top level GET_HW_INFO struct
if you want.
It does make a sense that an iommufd user would need to know that
information, especially width (but call it something better,
max_pasid_log2 or something) to successefully use the iommfd PASID
APIs anyhow.
I see, we may define the IOMMUFD_PASID_CAP_EXEC and IOMMUFD_PASID_CAP_PRIV
in the struct iommu_hw_info::out_capabilities, and add a max_pasid_log2 to
the struct iommu_hw_info.
However, I have one scalability concern. Do we only have PASID and PRI that
needs to be synthesized by userspace? For PRI, kernel would need to report
Outstanding Page Request Capacity to userspace. If only PASID and PRI cap,
it's fine. But if there are more such caps, then the struct iommu_hw_info
may grow bigger and bigger.
--
Regards,
Yi Liu
