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
