On 4/23/2020 12:44 PM, Jason Gunthorpe wrote:
The mdev utilizes Interrupt Message Store or IMS[3] instead of MSIX for
interrupts for the guest. This preserves MSIX for host usages and also allows a
significantly larger number of interrupt vectors for guest usage.
I never did get a reply to my earlier remarks on the IMS patches.
The concept of a device specific addr/data table format for MSI is not
Intel specific. This should be general code. We have a device that can
use this kind of kernel capability today.
I am sorry if I did not address your comments earlier.
It appears noboy from Intel bothered to answer anyone else on that RFC
thread:
https://lore.kernel.org/lkml/1568338328-22458-1-git-send-email-megha.dey@xxxxxxxxxxxxxxx/
However, it seems kind of moot as I see now that this verion of IMS
bears almost no resemblance to the original RFC.
hmm yeah, we changed most of the code after getting a lot of feedback
from you and folks at plumbers. But yes, I should have replied to all
the feedback, lesson learnt :)
That said, the similiarity to platform-msi was striking, does this new
version harmonize with that?
yes!
The present IMS code is quite generic, most of the code is in the drivers/
folder. We basically introduce 2 APIS: allocate and free IMS interrupts and
a IMS IRQ domain to allocate these interrupts from. These APIs are
architecture agnostic.
We also introduce a new IMS IRQ domain which is architecture specific. This
is because IMS generates interrupts only in the remappable format, hence
interrupt remapping should be enabled for IMS. Currently, the interrupt
remapping code is only available for Intel and AMD and I don’t see anything
for ARM.
I don't understand these remarks though - IMS is simply the mapping of
a MemWr addr/data pair to a Linux IRQ number? Why does this intersect
with remapping?
From your comments so far, I think your requirement is a subset of what
IMS is trying to do.
What you want:
have a dynamic means of allocating platform-msi interrupts
On top of this IMS has a requirement that all of the interrupts should
be remapped.
So we can have tiered code: generic dynamic platform-msi infrastructure
and add the IMS specific bits (Intel specific) on top of this.
The generic code will have no reference to IMS.
AFAIK, any platform that supports MSI today should have the inherent
HW capability to support IMS.
Also, could you give more details on the device that could use IMS? Do you
have some driver code already? We could then see if and how the current IMS
code could be made more generic.
We have several devices of interest, our NICs have very flexible PCI,
so it is no problem to take the MemWR addr/data from someplace other
than the MSI tables.
For this we want to have some way to allocate Linux IRQs dynamically
and get a addr/data pair to trigger them.
Our NIC devices are also linked to our ARM SOC family, so I'd expect
our ARM's to also be able to provide these APIs as the platform.
cool, so I will hope that you can test out the generic APIs from the ARM
side!
Jason
