From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by dpdk.org (Postfix) with ESMTP id AF6468D91 for ; Wed, 30 Sep 2015 15:05:42 +0200 (CEST) Received: by wicfx3 with SMTP id fx3so196491453wic.1 for ; Wed, 30 Sep 2015 06:05:42 -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=UdqM+oRTyENNxWv+uR4LK4ORihojh5hEjUUsdIXRJK0=; b=extzQDHqGUUgq7eCIceWpt5s3KcVdBOYRi+T2KoxwbSvTve2gudG7E65Zp0+WX7D3X /FDaXW65OgKY73Tnzh7hbI0466hAy4uz5NafYNFzdNXJSya3TWA0su4wiMFjLltTFToe HpaM8cTrGyjqMdzMcdEfpsPn+2BoxqOXtLlIKdq5xFySh0pQ9Uow35nByK/hWpew9tGQ dX+1Kf6zrPt6XPDDGZOPMjbtUgFI7ECWnJpSZAekSqKuFpQDINmYCKNqeid2wpnQ9lAy nBBZb+v5SrjheSl8FMn17gtrFdOiSGAzRDADUE0/tVM2oMRVMeQ4img4/xLIbmIk+0dH TL+g== X-Gm-Message-State: ALoCoQngUokomZZZl2WDfgHQpXWNxJ1T74sv1Av51tRyaXY0k8MMY/7PSyyn2sa8/ccSReqHH4hm X-Received: by 10.180.186.74 with SMTP id fi10mr29535865wic.61.1443618342457; Wed, 30 Sep 2015 06:05:42 -0700 (PDT) Received: from avi.cloudius ([37.142.229.250]) by smtp.googlemail.com with ESMTPSA id qq4sm589310wjc.14.2015.09.30.06.05.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Sep 2015 06:05:41 -0700 (PDT) To: "Michael S. Tsirkin" , Vlad Zolotarov 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> <20150930151632-mutt-send-email-mst@redhat.com> From: Avi Kivity Message-ID: <560BDE24.8000308@scylladb.com> Date: Wed, 30 Sep 2015 16:05:40 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150930151632-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 13:05:43 -0000 On 09/30/2015 03:27 PM, Michael S. Tsirkin wrote: > 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. Some setups don't need security (they are single-user, single application). But do need a lot of performance (like 5X-10X performance). An example is OpenVSwitch, security doesn't help it at all and if you force it to use the kernel drivers you cripple it. Also, I'm root. I can do anything I like, including loading a patched pci_uio_generic. You're not providing _any_ security, you're simply making life harder for users. > 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. I can adopt a new kernel tomorrow. I have no influence on EC2.