On 10/01/15 17:47, Stephen Hemminger wrote: > On Thu, 1 Oct 2015 11:00:28 +0300 > Vlad Zolotarov <vladz at cloudius-systems.com> wrote: > >> >> On 10/01/15 00:36, Stephen Hemminger wrote: >>> On Wed, 30 Sep 2015 23:09:33 +0300 >>> Vlad Zolotarov <vladz at cloudius-systems.com> wrote: >>> >>>> On 09/30/15 22:39, Michael S. Tsirkin wrote: >>>>> On Wed, Sep 30, 2015 at 10:06:52PM +0300, Vlad Zolotarov wrote: >>>>>>>> How would iommu >>>>>>>> virtualization change anything? >>>>>>> Kernel can use an iommu to limit device access to memory of >>>>>>> the controlling application. >>>>>> Ok, this is obvious but what it has to do with enabling using MSI/MSI-X >>>>>> interrupts support in uio_pci_generic? kernel may continue to limit the >>>>>> above access with this support as well. >>>>> It could maybe. So if you write a patch to allow MSI by at the same time >>>>> creating an isolated IOMMU group and blocking DMA from device in >>>>> question anywhere, that sounds reasonable. >>>> No, I'm only planning to add MSI and MSI-X interrupts support for >>>> uio_pci_generic device. >>>> The rest mentioned above should naturally be a matter of a different >>>> patch and writing it is orthogonal to the patch I'm working on as has >>>> been extensively discussed in this thread. >>>> >>> I have a generic MSI and MSI-X driver (posted earlier on this list). >>> About to post to upstream kernel. >> Stephen, hi! >> >> I found the mentioned series and first thing I noticed was that it's >> been sent in May so the first question is how far in your list of tasks >> submitting it upstream is? We need it more or less yesterday and I'm >> working on it right now. Therefore if u don't have time for it I'd like >> to help... ;) However I'd like u to clarify a few small things. Pls., >> see below... >> >> I noticed that u've created a separate msi_msix driver and the second >> question is what do u plan for the upstream? I was thinking of extending >> the existing uio_pci_generic with the MSI-X functionality similar to >> your code and preserving the INT#X functionality as it is now: > The igb_uio has a bunch of other things I didn't want to deal with: > the name (being specific to old Intel driver); compatibility with older > kernels; legacy ABI support. Therefore in effect uio_msi is a rebase > of igb_uio. > > The submission upstream yesterday is the first step, I expect lots > of review feedback.
Sure, we have lots of feedback already even before the patch has been sent... ;) So, I'm preparing the uio_pci_generic patch. Just wanted to make sure we are not working on the same patch at the same time... ;) It's going to enable both MSI and MSI-X support. For a backward compatibility it'll enable INT#X by default. It follows the concepts and uses some code pieces from your uio_msi patch. If u want I'll put u as a signed-off when I send it. > >> * INT#X and MSI would provide the IRQ number to the UIO module while >> only MSI-X case would register with UIO_IRQ_CUSTOM. > I wanted all IRQ's to be the same for the driver, ie all go through > eventfd mechanism. This makes code on DPDK side consistent with less > special cases. Of course. The name (uio_msi) is a bit confusing since it only adds MSI-X support. I mistakenly thought that it adds both MSI and MSI-X but it seems to only add MSI-X and then there are no further questions... ;) > >> I also noticed that u enable MSI-X on a first open() call. I assume >> there was a good reason (that I miss) for not doing it in probe(). Could >> u, pls., clarify? What about this?
