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 31E6D12A8 for ; Wed, 30 Sep 2015 12:58:15 +0200 (CEST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 8698DC0B1B2C; Wed, 30 Sep 2015 10:58:14 +0000 (UTC) Received: from redhat.com (ovpn-116-83.ams2.redhat.com [10.36.116.83]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id t8UAwCg2020899; Wed, 30 Sep 2015 06:58:12 -0400 Date: Wed, 30 Sep 2015 13:58:11 +0300 From: "Michael S. Tsirkin" To: Vlad Zolotarov Message-ID: <20150930134533-mutt-send-email-mst@redhat.com> 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> <560BBB62.3050502@cloudius-systems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <560BBB62.3050502@cloudius-systems.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 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:58:15 -0000 On Wed, Sep 30, 2015 at 01:37:22PM +0300, Vlad Zolotarov wrote: > > > 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. UIO doesn't enforce the IOMMU though. That's why it's not a good fit. > >>>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. Not only that, a bunch of boxes have their IOMMU disabled. So for such systems, you can't have userspace poking at device registers. You need a kernel driver to validate userspace requests before passing them on to devices. > 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. Of course it is lame. So don't bypass the kernel then, use the upstream drivers. > IMHO uio_pci_generic should > be fixed to be able to properly work within any virtualized environment and > not only with KVM. The motivation for UIO is pretty clear: For many types of devices, creating a Linux kernel driver is overkill. All that is really needed is some way to handle an interrupt and provide access to the memory space of the device. The logic of controlling the device does not necessarily have to be within the kernel, as the device does not need to take advantage of any of other resources that the kernel provides. One such common class of devices that are like this are for industrial I/O cards. Devices doing DMA do need to take advantage of memory protection that the kernel provides. > > > 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. > >