On Sun, May 03, 2020 at 03:31:39PM -0700, Dey, Megha wrote:
Hi Jason,
On 5/3/2020 3:22 PM, Jason Gunthorpe wrote:
On Fri, May 01, 2020 at 03:31:51PM -0700, Dey, Megha wrote:
This has been my concern reviewing the implementation. IMS needs more
than one in-tree user to validate degrees of freedom in the api. I had
been missing a second "in-tree user" to validate the scope of the
flexibility that was needed.
IMS is too narrowly specified.
All platforms that support MSI today can support IMS. It is simply a
way for the platform to give the driver an addr/data pair that triggers
an interrupt when a posted write is performed to that pair.
Well, yes and no. IMS requires interrupt remapping in addition to the
dynamic nature of IRQ allocation.
You've mentioned remapping a few times, but I really can't understand
why it has anything to do with platform_msi or IMS..
So after some internal discussions, we have concluded that IMS has no
linkage with Interrupt remapping, IR is just a platform concept. IMS is just
a name Intel came up with, all it really means is device managed addr/data
writes to generate interrupts. Technically we can call something IMS even if
device has its own location to store interrupts in non-pci standard
mechanism, much like platform-msi indeed. We simply need to extend
platform-msi to its address some of its shortcomings: increase number of
interrupts to > 2048, enable dynamic allocation of interrupts, add
mask/unmask callbacks in addition to write_msg etc.
Sounds right to me
Persumably you still need a way for the driver, eg vfio, to ensure a
MSI is remappable, but shouldn't that be exactly the same way as done
in normal PCI MSI today?
FWIW, even MSI can be IMS with rules on how to manage the addr/data writes
following pci sig .. its just that.
Yep, IMHO, our whole handling of MSI is very un-general sometimes..
I thought the msi_domain stuff that some platforms are using is a way
to improve on that? You might find that updating x86 to use msi_domain
might be helpful in this project???
Jason