From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by dpdk.org (Postfix) with ESMTP id 999328D95 for ; Wed, 30 Sep 2015 12:37:29 +0200 (CEST) Received: by wiclk2 with SMTP id lk2so191218027wic.0 for ; Wed, 30 Sep 2015 03:37:29 -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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=uWFcZeij5koy2qSLbWg6Hoa8Q53yPNQ42hyq3r2SpQQ=; b=gMUGVwIZxVSBfat+LalKkJK6qZcqdXxJrjmddEqVh/LUheUI8FP+AlIAEJmhwG48fo iaYLqi4hBZVPw8uVcN8hx7eXL3i1AB2xg0clF1F/uWw6zlpWSfjZv6PNWcEyYUUPTVfe Cql37j8gIEjfJ3EAYq80Lyi7jkt93uUb06L8qWoZsYf6RQypDjRMiarhTbNPadq2KmIh Nr3ME6wVgdVhZshqARlcH3UZSm7WFOqpG7oAWm+0E8I3VryfUFcnGBs2o9iF2oir7VJm WThTxRf2ZcW5c70U0bYfaVHfBY/XKEogCgdV5Z3BCXitQBJPryBmZZGh4tWv5vilhzau dMQw== X-Gm-Message-State: ALoCoQm3hM0qNiRulM79+Hyv2NKPYHOn1y6AI/mJx4h4sA/sg//h/nJi33uqFb9pqrQ9TBFeqpZY X-Received: by 10.180.109.135 with SMTP id hs7mr32062521wib.12.1443609449342; Wed, 30 Sep 2015 03:37:29 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-180-197-252.red.bezeqint.net. [79.180.197.252]) by smtp.googlemail.com with ESMTPSA id go5sm6099wib.3.2015.09.30.03.37.26 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Sep 2015 03:37:28 -0700 (PDT) To: "Michael S. Tsirkin" , Stephen Hemminger References: <56079527.3000802@cloudius-systems.com> <20150927123914-mutt-send-email-mst@redhat.com> <560ABF25.9030300@cloudius-systems.com> <20150929235122-mutt-send-email-mst@redhat.com> <20150929144616.4e70b44c@urahara> <20150930004714-mutt-send-email-mst@redhat.com> From: Vlad Zolotarov Message-ID: <560BBB62.3050502@cloudius-systems.com> Date: Wed, 30 Sep 2015 13:37:22 +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: <20150930004714-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" 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: Wed, 30 Sep 2015 10:37:29 -0000 On 09/30/15 00:49, Michael S. Tsirkin wrote: > On Tue, Sep 29, 2015 at 02:46:16PM -0700, Stephen Hemminger wrote: >> On Tue, 29 Sep 2015 23:54:54 +0300 >> "Michael S. Tsirkin" wrote: >> >>> On Tue, Sep 29, 2015 at 07:41:09PM +0300, Vlad Zolotarov wrote: >>>> The security breach motivation u brought in "[RFC PATCH] uio: >>>> uio_pci_generic: Add support for MSI interrupts" thread seems a bit weak >>>> since one u let the userland access to the bar it may do any funny thing >>>> using the DMA engine of the device. This kind of stuff should be prevented >>>> using the iommu and if it's enabled then any funny tricks using MSI/MSI-X >>>> configuration will be prevented too. >>>> >>>> I'm about to send the patch to main Linux mailing list. Let's continue this >>>> discussion there. >>>> >>> Basically UIO shouldn't be used with devices capable of DMA. >>> Use VFIO for that (yes, this implies an emulated or PV IOMMU). If there is an IOMMU in the picture there shouldn't be any problem to use UIO with DMA capable devices. >>> I don't think this can change. >> Given there is no PV IOMMU and even if there was it would be too slow for DPDK >> use, I can't accept that. > QEMU does allow emulating an iommu. Amazon's EC2 xen HV doesn't. At least today. Therefore VFIO is not an option there. And again, it's a general issue not DPDK specific. Today one has to develop some proprietary modules (like igb_uio) to workaround the issue and this is lame. IMHO uio_pci_generic should be fixed to be able to properly work within any virtualized environment and not only with KVM. > DPDK uses static mappings, so I > doubt it's speed matters at all. > > Anyway, DPDK is doing polling all the time. I don't see why does it > insist on using interrupts to detect link up events. Just poll for that > too. >