[dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance

[Stephen Hemminger]

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.

>   *   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.

> 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?