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

[Nicolin Chen]

On Tue, Dec 10, 2024 at 08:48:21PM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 10, 2024 at 03:01:48PM -0800, Nicolin Chen wrote:
> 
> > Yet, here we seem to be missing a pathway between VMM and kernel
> > to agree on the MSI window decided by the kernel, as this patch
> > does the hard coding for a [0x8000000, 0x8100000) range.
> 
> 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..

> The SW_MSI range then becomes something just used "by default".
>
> Haven't thought about exactly which ioctl could do
> this.. SET_OPTION(SW_MSI) on the idevice perhaps?
> 
> It seems pretty simple to do?

That looks like a good interface, given that we are already
making sw_msi_list per ictx.

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.

> We will eventually need a way for userspace to disable SW_MSI entirely
> anyhow.

> > I have been going through the structures between QEMU's SMMU code
> > and virt/virt-acpi-build code, yet having a hard time to figure
> > out a way to forward the MSI window from the SMMU code to IORT,
> > especially after this series changes the "smmu" instance creation
> > from virt code to "-device" string. Any thought?
> 
> You probably have to solve this eventually because when the kernel
> supports a non-RMR path the IORT code will need to not create the RMR
> too.
> 
> Using RMR, or not, and the address to put the SW_MSI, is probably part
> of the global machine configuration in qemu.

Yes, either vITS or RMR range is in the global machine code.
So, likely it's not ideal to go with HWPTs.

Thanks!
Nicolin