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 38E0B8E67 for ; Thu, 1 Oct 2015 11:15:24 +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 116C98E688; Thu, 1 Oct 2015 09:15:23 +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 ESMTP id t919FJnZ007166; Thu, 1 Oct 2015 05:15:20 -0400 Date: Thu, 1 Oct 2015 12:15:18 +0300 From: "Michael S. Tsirkin" To: Avi Kivity Message-ID: <20151001120027-mutt-send-email-mst@redhat.com> References: <560BD284.7040505@cloudius-systems.com> <20150930151632-mutt-send-email-mst@redhat.com> <560BDE24.8000308@scylladb.com> <20150930165359-mutt-send-email-mst@redhat.com> <560BF782.4070308@scylladb.com> <20150930175848-mutt-send-email-mst@redhat.com> <560C0171.7080507@scylladb.com> <20150930204016.GA29975@redhat.com> <20151001113828-mutt-send-email-mst@redhat.com> <560CF44A.60102@scylladb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <560CF44A.60102@scylladb.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: Thu, 01 Oct 2015 09:15:24 -0000 On Thu, Oct 01, 2015 at 11:52:26AM +0300, Avi Kivity wrote: > I still don't understand your objection to the patch: > > > MSI messages are memory writes so any generic device capable > of MSI is capable of corrupting kernel memory. > This means that a bug in userspace will lead to kernel memory corruption > and crashes. This is something distributions can't support. > > > If a distribution feels it can't support this configuration, it can disable the > uio_pci_generic driver, or refuse to support tainted kernels.  If it feels it > can (and many distributions are starting to support dpdk), then you're just > denying it the ability to serve its users. I don't, and can't deny users anything. I merely think upstream should avoid putting this driver in-tree. By doing this, driver writers will be pushed to develop solutions that can't crash kernel. I pointed out one way to build it, there are sure to be more. As far as I could see, without this kind of motivation, people do not even want to try. -- MST