From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751552AbbJEVzA (ORCPT ); Mon, 5 Oct 2015 17:55:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38058 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751239AbbJEVy7 (ORCPT ); Mon, 5 Oct 2015 17:54:59 -0400 Date: Tue, 6 Oct 2015 00:54:55 +0300 From: "Michael S. Tsirkin" To: Stephen Hemminger Cc: hjk@hansjkoch.de, gregkh@linux-foundation.org, linux-kernel@vger.kernel.org, dev@dpdk.org Subject: Re: [PATCH 2/2] uio: new driver to support PCI MSI-X 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> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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