From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by dpdk.org (Postfix) with ESMTP id 3335C8E5A for ; Thu, 1 Oct 2015 10:00:30 +0200 (CEST) Received: by wiclk2 with SMTP id lk2so20400779wic.0 for ; Thu, 01 Oct 2015 01:00:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=81hWYn69gA0c7VNoR6tSHA5aIifytX9WevXy5F/Th6o=; b=dmvh/DMNQsfapBffUFYRzWPMDlWJBXq6+vMGe5yoqVMqPnftAuymhePgpHOcN4y1b8 c9ONUp9R1voxrKZ+o/7DhLORTt6kw7eFNEdKkg5LRuYNDDCd8jNbuYJb2oRoVRwsJGSo U3Mxoa6kVraf4BWNLMSNRtcpsDI+pOdwGjKF7Ct1N3N72K50m5EgpyMjHVvI+3ciW6+U DySEhv0atUKKHElJo7EdLZ/rUz5h+kHAR97Iif0swbeKcfpuY9mnK3p9dRVlF60nhicW TIOxivsBnLXCrZ5PdEHxt6YkIUELDy7I1cYH+ggt3W/M6zaCW+yzDjpqL9V84aGbGqhc T+3w== X-Gm-Message-State: ALoCoQmmzmnLfTrXmCi1lOXdoKY7HLsyGBudFaoecBIyXExh8qhn+4VuSHkxlj8YyHtZUF1bY0JJ X-Received: by 10.194.234.71 with SMTP id uc7mr8861631wjc.105.1443686429853; Thu, 01 Oct 2015 01:00:29 -0700 (PDT) Received: from [10.0.0.165] ([37.142.229.250]) by smtp.googlemail.com with ESMTPSA id uq5sm4800374wjc.3.2015.10.01.01.00.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2015 01:00:28 -0700 (PDT) To: Stephen Hemminger 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> From: Vlad Zolotarov Message-ID: <560CE81C.3050004@cloudius-systems.com> Date: Thu, 1 Oct 2015 11:00:28 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150930143648.4b98db81@urahara> Content-Type: text/plain; charset=windows-1252; format=flowed 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 08:00:30 -0000 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: * 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 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?