Re: [RFC PATCH 5/5] hw/arm/virt-acpi-build: Add IORT RMR regions to handle MSI nested binding

[Jason Gunthorpe <jgg@nvidia.com>]

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