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.
Jason
