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 75D0F9269 for ; Mon, 5 Oct 2015 23:55:00 +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 548482FE83E; Mon, 5 Oct 2015 21:54:59 +0000 (UTC) Received: from redhat.com (ovpn-116-21.ams2.redhat.com [10.36.116.21]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id t95Lsuar002988; Mon, 5 Oct 2015 17:54:57 -0400 Date: Tue, 6 Oct 2015 00:54:55 +0300 From: "Michael S. Tsirkin" To: Stephen Hemminger Message-ID: <20151005215455.GA7608@redhat.com> References: <1443652138-31782-1-git-send-email-stephen@networkplumber.org> <1443652138-31782-3-git-send-email-stephen@networkplumber.org> <20151001104505-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151001104505-mutt-send-email-mst@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: dev@dpdk.org, hjk@hansjkoch.de, gregkh@linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X 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: Mon, 05 Oct 2015 21:55:00 -0000 On Thu, Oct 01, 2015 at 11:33:06AM +0300, Michael S. Tsirkin wrote: > Just forwarding events is not enough to make a valid driver. > What is missing is a way to access the device in a safe way. Thinking about it some more, maybe some devices don't do DMA, and merely signal events with MSI/MSI-X. The fact you mention igb_uio in the cover letter seems to hint that this isn't the case, and that the real intent is to abuse it for DMA-capable devices, but still ... If we assume such a simple device, we need to block userspace from tweaking at least the MSI control and the MSI-X table. And changing BARs might make someone else corrupt the MSI-X table, so we need to block it from changing BARs, too. Things like device reset will clear the table. I guess this means we need to track access to reset, too, make sure we restore the table to a sane config. PM capability can be used to reset things tooI think. Better be careful about that. And a bunch of devices could be doing weird things that need to be special-cased. All of this is what VFIO is already dealing with. Maybe extending VFIO for this usecase, or finding another way to share code might be a better idea than duplicating the code within uio? -- MST