From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755175AbbJGQjX (ORCPT ); Wed, 7 Oct 2015 12:39:23 -0400 Received: from mail-wi0-f181.google.com ([209.85.212.181]:33168 "EHLO mail-wi0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753882AbbJGQjU (ORCPT ); Wed, 7 Oct 2015 12:39:20 -0400 Subject: Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support To: Alex Williamson 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> <5614C11B.6090601@scylladb.com> <1444235464.4059.169.camel@redhat.com> 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 From: Avi Kivity Message-ID: <56154AB4.1050509@scylladb.com> Date: Wed, 7 Oct 2015 19:39:16 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1444235464.4059.169.camel@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/07/2015 07:31 PM, Alex Williamson wrote: >>> I >>> guess the no-iommu map would error if the IOVA isn't simply the bus >>> address of the page mapped. >>> >>> 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. >> There is an additional complication. With an iommu, userspace programs >> the device with virtual addresses, but without it, they have to program >> physical addresses. So vfio would need to communicate this bit of >> information. >> >> We can go further and define a better translation API than the current >> one (reading /proc/pagemap). But it's going to be a bigger change to >> vfio than I thought at first. > 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. That's what I thought as well, but apparently adding msix support to the already insecure uio drivers is even worse.