On Wed, Dec 11, 2024 at 09:20:20AM -0800, Nicolin Chen wrote:
> 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?
There are two parts to the vITS flow:
1) mapping the phsical ITS page - I expect this to go through
IOMMUFD_CMD_IOAS_MAP_FILE
2) Conveying the MSI addr per-irq - this doesn't feel like set_option
is quite the right fit since it is an array of msis
>
> > > 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).
Maybe length, but yes
> 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?
Ideally the kernel would detect and fail IRQ setup in these cases.
I suggest enforcing a minimal range of something XXM big at least,
then it won't happen.
Jason
