From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755919AbbJGUFm (ORCPT ); Wed, 7 Oct 2015 16:05:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56612 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751605AbbJGUFl (ORCPT ); Wed, 7 Oct 2015 16:05:41 -0400 Date: Wed, 7 Oct 2015 23:05:32 +0300 From: "Michael S. Tsirkin" To: Alex Williamson Cc: Avi Kivity , 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 Subject: Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support Message-ID: <20151007225835-mutt-send-email-mst@redhat.com> References: <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> <5614C11B.6090601@scylladb.com> <1444235464.4059.169.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1444235464.4059.169.camel@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 07, 2015 at 10:31:04AM -0600, Alex Williamson wrote: > It sounds like a separate vfio iommu backend from type1, one that just > pins the page and returns the bus address. The curse and benefit would > be that existing type1 users wouldn't "just work" in an insecure mode, > the DMA mapping code would need to be aware of the difference. Still, I > do really prefer to keep vfio as only exposing a secure, iommu protected > device to the user because surely someone will try and users would > expect that removing iommu restrictions from vfio means they can do > device assignment to VMs w/o an iommu. What I had in mind is rather reusing vfio code. What is needed is all the logic for handling device reset, protecting BARs and config space regions, MSI/MSI-X and device-specific work-arounds. Also, all the interface things such as eventfd. But I don't think it should be the same char device as vfio - /dev/vfio/vfio is world-accessible - should be a separate non-world accessible device, maybe /dev/vfio/noiommu. This will ensure e.g. qemu does not attempts to use it automatically. -- MST