From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by dpdk.org (Postfix) with ESMTP id 1F3E9683D for ; Tue, 31 Mar 2015 14:41:56 +0200 (CEST) Received: by lajy8 with SMTP id y8so11564842laj.0 for ; Tue, 31 Mar 2015 05:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Fxj7RB+rC0rJ6CUIlCFd5h732aXWiRKxX7mNVdOy/Yc=; b=rLJ43JoV5ffi7VhkZGe0thRHuXCGZnAP3jfqSZvMuetkUYcfmFQKmtlh89ku5JIiHY Hw+dpbxaKa0JuK7k5Jc6PcBCSEZ6wH+5P1PkilUJv18Rxg+ReB1eGBZ4qOdegT8VTKYu /KlGDMoMLEdgT16whensZazLYoKKAZULxH2pEk8xHtMSbA+y6d5nS0r6qDjWlqG3IKKS zEocGUXow8wFECPduO02/TsVprhPkfZGZnYZ0fsESHFJztXzQvHlsmcjHbflSLQnJ2d4 oigNcnIvp0MQJAZyhIJ9mSieIBdfGd+8AQZp9ypKc6bALAC19vb5yuZI0PkaYkdM4QZ/ 0nrA== MIME-Version: 1.0 X-Received: by 10.152.44.200 with SMTP id g8mr8633694lam.46.1427805715839; Tue, 31 Mar 2015 05:41:55 -0700 (PDT) Received: by 10.112.207.65 with HTTP; Tue, 31 Mar 2015 05:41:55 -0700 (PDT) In-Reply-To: References: <20150330133507.77ff6b1d@urahara> <20150330133742.57adef52@urahara> Date: Tue, 31 Mar 2015 14:41:55 +0200 Message-ID: From: Andre Richter To: "Burakov, Anatoly" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] VFIO in setup.sh 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: Tue, 31 Mar 2015 12:41:56 -0000 2015-03-31 11:35 GMT+02:00 Burakov, Anatoly : > > > I think the whole process of VFIO binding maybe needs at least a second= thought regarding corner cases and security. > > > > 1) in the setup process, there currently is no mechanism that checks if= the Device to be used has other devices in the > > same iommu group that need to be bound to VFIO too. Otherwise using VFI= O will fail. > > I think currently, it only works if the network device is the only one = in its iommu group. > > > > 2) Right now everything inside /dev/vfio/ is granted to the all users, = right? Maybe this leads to (security) issues if VFIO > > is in active use by other non-dpdk processes for other PCIe devices. > > I believe that's how VFIO is meant to be used. At least according to VFIO= documentation, located here: https://www.kernel.org/doc/Documentation/vfio= .txt > > Regarding 1), this can only be done by unbinding the device from the host= driver and binding it to vfio-pci, which can't be done by the user. If the= device is not bound to vfio-pci, we have no way of knowing if it belongs t= o this or that IOMMU group. iommu groups already exist before vfio-pci is loaded. The whole setup process as described in the VFIO documentation, where a PCIe device shares an iommu group with other devices, can therefore be automated. Some time ago I wrote a ruby script that does exactly that (https://github.com/andre-richter/rVFIO/blob/master/example/pci-bind.r= b). Porting it to bash should be no problem. However, the question is if dpdk needs to cover this (corner?) case. I would assume that the bulk of dpdk use-cases deals with scenarios where the targeted NIC is the only one in its iommu group, because it is a high-speed NIC that is connected to a CPU-integrated PCIe-Port. A NIC sharing an iommu group with other devices would be most likely if it is behind a bridge, aka a chipset-integrated NIC or a NIC that resides in a PCIe-Slot that connects to the chipset. This is more common in desktop machines than in server grade machines. Cheers, Andre > > Regarding 2), as noted above, the administrator should set up VFIO device= s. While I agree that the way setup.sh sets up VFIO security permissions is= not ideal, it's really there to cover the most common use case. An adminis= trator can always set up VFIO on his own, granting permissions as needed. > > Thanks, > Anatoly