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 C33478E5A for ; Thu, 1 Oct 2015 13:31:39 +0200 (CEST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 2CF0B7A; Thu, 1 Oct 2015 11:31:39 +0000 (UTC) Received: from redhat.com (ovpn-116-83.ams2.redhat.com [10.36.116.83]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id t91BVaC0032263; Thu, 1 Oct 2015 07:31:37 -0400 Date: Thu, 1 Oct 2015 14:31:35 +0300 From: "Michael S. Tsirkin" To: Avi Kivity Message-ID: <20151001142843-mutt-send-email-mst@redhat.com> References: <20151001113828-mutt-send-email-mst@redhat.com> <560CF44A.60102@scylladb.com> <20151001120027-mutt-send-email-mst@redhat.com> <560CFB66.5050904@scylladb.com> <20151001124211-mutt-send-email-mst@redhat.com> <560D0413.5080401@scylladb.com> <20151001131754-mutt-send-email-mst@redhat.com> <560D0FE2.7010905@scylladb.com> <20151001135054-mutt-send-email-mst@redhat.com> <560D1705.30300@scylladb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <560D1705.30300@scylladb.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 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: Thu, 01 Oct 2015 11:31:40 -0000 On Thu, Oct 01, 2015 at 02:20:37PM +0300, Avi Kivity wrote: > > > On 10/01/2015 02:09 PM, Michael S. Tsirkin wrote: > >On Thu, Oct 01, 2015 at 01:50:10PM +0300, Avi Kivity wrote: > >>>>It's not just the lack of system calls, of course, the architecture is > >>>>completely different. > >>>Absolutely - I'm not saying move all of DPDK into kernel. > >>>We just need to protect the RX rings so hardware does > >>>not corrupt kernel memory. > >>> > >>> > >>>Thinking about it some more, many devices > >>>have separate rings for DMA: TX (device reads memory) > >>>and RX (device writes memory). > >>>With such devices, a mode where userspace can write TX ring > >>>but not RX ring might make sense. > >>I'm sure you can cause havoc just by reading, if you read from I/O memory. > >Not talking about I/O memory here. These are device rings in RAM. > > Right. But you program them with DMA addresses, so the device can read > another device's memory. It can't if host has limited it to only DMA into guest RAM, which is pretty common. -- MST