From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753430AbbJHH7P (ORCPT ); Thu, 8 Oct 2015 03:59:15 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:35065 "EHLO mail-wi0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751259AbbJHH7O (ORCPT ); Thu, 8 Oct 2015 03:59:14 -0400 Date: Thu, 8 Oct 2015 10:59:10 +0300 From: Gleb Natapov To: "Michael S. Tsirkin" Cc: Avi Kivity , Alex Williamson , 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: <20151008075910.GD11716@scylladb.com> References: <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> <56154AB4.1050509@scylladb.com> <20151007230553-mutt-send-email-mst@redhat.com> <20151008041913.GB13818@scylladb.com> <20151008074153.GB19331@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151008074153.GB19331@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 08, 2015 at 10:41:53AM +0300, Michael S. Tsirkin wrote: > On Thu, Oct 08, 2015 at 07:19:13AM +0300, Gleb Natapov wrote: > > Well > > the alternative is to add /dev/vfio/nommu like you've said, but what > > would be the difference between this and uio eludes me. > > Are you familiar with vfio that you ask such a question? > Yes, I do and I do not see anything of value that vfio can add to nommu setup besides complexity, but I do see why it will have to have special interface not applicable to regular vfio (hint: there is not HW to translate virtual address to physical) and why it will have to be accessible to root user only. > Here's the vfio pci code: > > $ wc -l drivers/vfio/pci/* > 27 drivers/vfio/pci/Kconfig > 4 drivers/vfio/pci/Makefile > 1217 drivers/vfio/pci/vfio_pci.c > 1602 drivers/vfio/pci/vfio_pci_config.c > 675 drivers/vfio/pci/vfio_pci_intrs.c > 92 drivers/vfio/pci/vfio_pci_private.h > 238 drivers/vfio/pci/vfio_pci_rdwr.c > 3855 total > > There's some code dealing with iommu groups in > drivers/vfio/pci/vfio_pci.c, > but most of it is validating input and > presenting a consistent interface to userspace. > What is has to do with the patch series in question? Non patched uio_generic code does not validate input. If you think it should by all means write the code (don't break existing use cases while doing so), but the patch under discussion does not even access pci device from userspace, so it will not be affected by said filtering. > This is exactly what's missing here. It is not missing in this patch series, it is missing from upstream code. I do not remember this been an issue when uio_generic was accepted into the kernel. The reason was because it meant to be accessible by root only. VFIO was designed to be used by regular user from ground up, so obviously unrestricted access to pci space was out of the question. Different use cases lead to different designs, how surprising. > > There's also drivers/vfio/virqfd.c which deals > with sending interrupts over eventfds correctly. > As opposite to this patch that deals with them incorrectly? In what way? -- Gleb.