From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934165AbbJHPbb (ORCPT ); Thu, 8 Oct 2015 11:31:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50956 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933645AbbJHPba (ORCPT ); Thu, 8 Oct 2015 11:31:30 -0400 Message-ID: <1444318288.4059.191.camel@redhat.com> Subject: Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support From: Alex Williamson To: Avi Kivity Cc: "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, stephen@networkplumber.org, alexander.duyck@gmail.com Date: Thu, 08 Oct 2015 09:31:28 -0600 In-Reply-To: <56166D8C.8080505@scylladb.com> References: <20151006174648-mutt-send-email-mst@redhat.com> <5613E75E.1040002@scylladb.com> <1444157480.4059.67.camel@redhat.com> <5614C11B.6090601@scylladb.com> <1444235464.4059.169.camel@redhat.com> <56154AB4.1050509@scylladb.com> <20151007230553-mutt-send-email-mst@redhat.com> <56160039.4090901@scylladb.com> <20151008104212-mutt-send-email-mst@redhat.com> <56163518.2030007@scylladb.com> <20151008123839-mutt-send-email-mst@redhat.com> <56166D8C.8080505@scylladb.com> 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 Thu, 2015-10-08 at 16:20 +0300, Avi Kivity wrote: > On 10/08/2015 01:26 PM, Michael S. Tsirkin wrote: > > On Thu, Oct 08, 2015 at 12:19:20PM +0300, Avi Kivity wrote: > >> We are in the strange situation that the Alex is open to adding an insecure > >> mode to vfio, > > I don't find this strange. It seems to make sense. VFIO is > > already used with DMA capable devices. > > It's strange to me because it's charter was for iommu-protected device > assignment, while uio_pci_generic is for generic pci userspace. To be clear, I'm not necessarily advocating an insecure mode of vfio, I'm pointing out that vfio is built on the security, isolation, and services advertised by the iommu layer. That layer doesn't exist in a no-iommu system, but a stub iommu driver that disregards the intended purpose of iommu groups and implements those services could likely fool vfio into working. From a code re-use standpoint, there are some clear advantages to doing that even though it's rather dastardly at the iommu level. There's not too much I can do to prevent such a thing, vfio has to trust someone and in this case it's the core kernel iommu services. So if such a task was attempted, I'd want to be involved and enlighten vfio at least to the point where we can make it clear to users which uses are secure and which are not. Thanks, Alex