From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 0B4055A55 for ; Wed, 30 Sep 2015 14:27:12 +0200 (CEST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 2FE91341AF6; Wed, 30 Sep 2015 12:27:11 +0000 (UTC) Received: from redhat.com (ovpn-116-83.ams2.redhat.com [10.36.116.83]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id t8UCR8DF032445; Wed, 30 Sep 2015 08:27:09 -0400 Date: Wed, 30 Sep 2015 15:27:07 +0300 From: "Michael S. Tsirkin" To: Vlad Zolotarov Message-ID: <20150930151632-mutt-send-email-mst@redhat.com> References: <20150929235122-mutt-send-email-mst@redhat.com> <20150929144616.4e70b44c@urahara> <20150930004714-mutt-send-email-mst@redhat.com> <560BBB62.3050502@cloudius-systems.com> <20150930134533-mutt-send-email-mst@redhat.com> <560BC6C9.4020505@cloudius-systems.com> <20150930143927-mutt-send-email-mst@redhat.com> <560BCD2F.5060505@cloudius-systems.com> <20150930150115-mutt-send-email-mst@redhat.com> <560BD284.7040505@cloudius-systems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <560BD284.7040505@cloudius-systems.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 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 12:27:12 -0000 On Wed, Sep 30, 2015 at 03:16:04PM +0300, Vlad Zolotarov wrote: > > > On 09/30/15 15:03, Michael S. Tsirkin wrote: > >On Wed, Sep 30, 2015 at 02:53:19PM +0300, Vlad Zolotarov wrote: > >> > >>On 09/30/15 14:41, Michael S. Tsirkin wrote: > >>>On Wed, Sep 30, 2015 at 02:26:01PM +0300, Vlad Zolotarov wrote: > >>>>The whole idea is to bypass kernel. Especially for networking... > >>>... on dumb hardware that doesn't support doing that securely. > >>On a very capable HW that supports whatever security requirements needed > >>(e.g. 82599 Intel's SR-IOV VF devices). > >Network card type is irrelevant as long as you do not have an IOMMU, > >otherwise you would just use e.g. VFIO. > > Sorry, but I don't follow your logic here - Amazon EC2 environment is a > example where there *is* iommu but it's not virtualized > and thus VFIO is > useless and there is an option to use directly assigned SR-IOV networking > device there where using the kernel drivers impose a performance impact > compared to user space UIO-based user space kernel bypass mode of usage. How > is it irrelevant? Could u, pls, clarify your point? > So it's not even dumb hardware, it's another piece of software that forces an "all or nothing" approach where either device has access to all VM memory, or none. And this, unfortunately, leaves you with no secure way to allow userspace drivers. So it makes even less sense to add insecure work-arounds in the kernel. It seems quite likely that by the time the new kernel reaches production X years from now, EC2 will have a virtual iommu. > > > >>>Colour me unimpressed. > >>>