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
