On Wed, Dec 11, 2024 at 09:11:12AM -0400, Jason Gunthorpe wrote: > On Tue, Dec 10, 2024 at 05:28:17PM -0800, Nicolin Chen wrote: > > > I would ideally turn it around and provide that range information to > > > the kernel and totally ignore the SW_MSI reserved region once > > > userspace provides it. > > > > Hmm.. that sounds like a uAPI for vITS range..but yes.. > > It controls the window that the kernel uses to dynamically map the ITS > pages.
Can we use SET_OPTION for vITS mapping (non-RMR solution) too? > > So, VMM can GET_OPTION(SW_MSI) for msi_base to extract the > > info from kernel. Likely need a second call for its length? > > Since IOMMU_OPTION only supports one val64 input or output. > > No, just forget about the kernel's SW_MSI region. The VMM uses this > API and overrides it and iommufd completely ignores SW_MSI. > > There is nothing special about the range hard coded into the smmu > driver. OK. We will have SET_OPTION(IOMMU_OPTION_SW_MSI_START) and SET_OPTION(IOMMU_OPTION_SW_MSI_LAST). I think we will need some validation to the range too, although iommufd doesn't have the information about the underlying ITS driver: what if user space sets range to a page size, while the ITS driver requires multiple pages? Thanks Nicolin
