From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753263AbbJFPXR (ORCPT ); Tue, 6 Oct 2015 11:23:17 -0400 Received: from mail-wi0-f180.google.com ([209.85.212.180]:33437 "EHLO mail-wi0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752671AbbJFPXO (ORCPT ); Tue, 6 Oct 2015 11:23:14 -0400 Subject: Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support To: "Michael S. Tsirkin" , Vlad Zolotarov 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> Cc: 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, Alex Williamson From: Avi Kivity Message-ID: <5613E75E.1040002@scylladb.com> Date: Tue, 6 Oct 2015 18:23:10 +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: <20151006174648-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252; 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/06/2015 05:56 PM, Michael S. Tsirkin wrote: > On Tue, Oct 06, 2015 at 05:43:50PM +0300, Vlad Zolotarov wrote: >> The only "like VFIO" behavior we implement here is binding the MSI-X >> interrupt notification to eventfd descriptor. > There will be more if you add some basic memory protections. > > Besides, that's not true. > Your patch queries MSI capability, sets # of vectors. > You even hinted you want to add BAR mapping down the road. BAR mapping is already available from sysfs; it is not mandatory. > VFIO does all of that. > Copying vfio maintainer Alex (hi!). vfio's charter is modern iommu-capable configurations. It is designed to be secure enough to be usable by an unprivileged user. For performance and hardware reasons, many dpdk deployments use uio_pci_generic. They are willing to trade off the security provided by vfio for the performance and deployment flexibility of pci_uio_generic. Forcing these features into vfio will compromise its security and needlessly complicate its code (I guess it can be done with a "null" iommu, but then vfio will have to decide whether it is secure or not). >> This doesn't justifies the >> hassle of implementing IOMMU-less VFIO mode. > This applies to both VFIO and UIO really. I'm not sure the hassle of > maintaining this functionality in tree is justified. It remains to be > seen whether there are any users that won't taint the kernel. > Apparently not in the current form of the patch, but who knows. It is not msix that taints the kernel, it's uio_pci_generic. Msix is a tiny feature addition that doesn't change the security situation one bit. btw, currently you can map BARs and dd to /dev/mem to your heart's content without tainting the kernel. I don't see how you can claim that msix support makes the situation worse, when root can access every bit of physical memory, either directly or via DMA.