From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752599AbbJFO4P (ORCPT ); Tue, 6 Oct 2015 10:56:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55066 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751460AbbJFO4O (ORCPT ); Tue, 6 Oct 2015 10:56:14 -0400 Date: Tue, 6 Oct 2015 17:56:07 +0300 From: "Michael S. Tsirkin" To: Vlad Zolotarov Cc: Avi Kivity , 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: <20151006174648-mutt-send-email-mst@redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5613DE26.1090202@cloudius-systems.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. VFIO does all of that. > 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. -- MST