Re: [PATCH RFC 00/15] Add VFIO mediated device support and IMS support for the idxd driver.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux