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

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?

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.

Jason