From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753104AbbJFVlu (ORCPT ); Tue, 6 Oct 2015 17:41:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37422 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752313AbbJFVlt (ORCPT ); Tue, 6 Oct 2015 17:41:49 -0400 Message-ID: <1444167707.4059.88.camel@redhat.com> Subject: Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support From: Alex Williamson To: Stephen Hemminger Cc: Avi Kivity , "Michael S. Tsirkin" , Vlad Zolotarov , Greg KH , linux-kernel@vger.kernel.org, hjk@hansjkoch.de, corbet@lwn.net, bruce.richardson@intel.com, avi@cloudius-systems.com, gleb@cloudius-systems.com, alexander.duyck@gmail.com Date: Tue, 06 Oct 2015 15:41:47 -0600 In-Reply-To: <20151006223202.66ab0b87@samsung9> References: <1443991398-23761-1-git-send-email-vladz@cloudius-systems.com> <1443991398-23761-3-git-send-email-vladz@cloudius-systems.com> <20151005031159.GB27303@kroah.com> <56123493.9000602@scylladb.com> <20151005094932.GA5236@kroah.com> <56124EDB.3070701@scylladb.com> <20151006143821.GA11541@redhat.com> <5613DE26.1090202@cloudius-systems.com> <20151006174648-mutt-send-email-mst@redhat.com> <5613E75E.1040002@scylladb.com> <1444157480.4059.67.camel@redhat.com> <20151006223202.66ab0b87@samsung9> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2015-10-06 at 22:32 +0100, Stephen Hemminger wrote: > On Tue, 06 Oct 2015 12:51:20 -0600 > Alex Williamson wrote: > > > Of course this is entirely unsafe and this no-iommu driver should taint > > the kernel, but it at least standardizes on one userspace API and you're > > already doing completely unsafe things with uio. vfio should be > > enlightened at least to the point that it allows only privileged users > > access to devices under such a (lack of) iommu > > I agree with the design, but not with the taint argument. > (Unless you want to taint any and all use of UIO drivers which can > already do this). Yes, actually, if the bus master bit gets enabled all bets are off. I don't see how that leaves a supportable kernel, so we might as well taint it. Isn't this exactly why we taint for proprietary drivers, we have no idea what it has mucked with in kernel space. This just moves the proprietary driver out to userspace without an iommu to protect the host. Thanks, Alex