From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by dpdk.org (Postfix) with ESMTP id 0FF708E65 for ; Thu, 1 Oct 2015 16:47:06 +0200 (CEST) Received: by pacfv12 with SMTP id fv12so78251150pac.2 for ; Thu, 01 Oct 2015 07:47:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=W5ycKJ2WuBmVaW79W+yqIdYG65aUTYTPYyMriKiCj0w=; b=jf4Nl+gA2Zb2TlCbaoffMJWcv1JgtwyutaxOUIoPdk/SAUnMywWamvqdwY7ylOzN/S Atda0xDxcwn4SOjde4R0jfit1YqP5cER70iZpTW7zL5Itiya4vCB9qGBZg4MEsytegMH PVc17Osol28YVah0iTx0lXXDZNmx9C+HJy05yXiDRAX0qJI+3FVRCwGRhTRWm+VAbDbT qYOcWjrHKOZTT1jZ5MagdHNo6zJf6jBVp8SBVeqeOnZ4OyhNOd1xID19TrqkWCw6HowH gPhtspAkxKe0xhWlOjJxxe31DbGyf1lVluAZBP4yu0oMiebDEEX+jiE1LxCq7NvwwBHM vu4g== X-Gm-Message-State: ALoCoQmSUwUqLT96k+Y89PTH+TAoZ3r2XL+cYGLY5K8UP8nG8GNnM3dXV1DxuYTQjo1EK1TER5il X-Received: by 10.68.237.196 with SMTP id ve4mr12678838pbc.98.1443710825338; Thu, 01 Oct 2015 07:47:05 -0700 (PDT) Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by smtp.gmail.com with ESMTPSA id or6sm7156071pac.32.2015.10.01.07.47.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2015 07:47:05 -0700 (PDT) Date: Thu, 1 Oct 2015 07:47:14 -0700 From: Stephen Hemminger To: Vlad Zolotarov Message-ID: <20151001074714.5f6cc100@urahara> In-Reply-To: <560CE81C.3050004@cloudius-systems.com> References: <20150930143927-mutt-send-email-mst@redhat.com> <560BCD2F.5060505@cloudius-systems.com> <20150930150115-mutt-send-email-mst@redhat.com> <560BD284.7040505@cloudius-systems.com> <20150930151632-mutt-send-email-mst@redhat.com> <560BDA81.6070807@cloudius-systems.com> <20150930182155-mutt-send-email-mst@redhat.com> <560C26DC.80209@cloudius-systems.com> <20150930215027-mutt-send-email-mst@redhat.com> <560C32CC.90708@cloudius-systems.com> <20150930222910-mutt-send-email-mst@redhat.com> <560C417D.1050409@cloudius-systems.com> <20150930143648.4b98db81@urahara> <560CE81C.3050004@cloudius-systems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" , "Michael S. Tsirkin" Subject: Re: [dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 14:47:06 -0000 On Thu, 1 Oct 2015 11:00:28 +0300 Vlad Zolotarov wrote: > > > On 10/01/15 00:36, Stephen Hemminger wrote: > > On Wed, 30 Sep 2015 23:09:33 +0300 > > Vlad Zolotarov 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?