From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: UIO: missing resource mapping Date: Fri, 13 Jul 2012 16:22:23 +0300 Message-ID: <20120713132223.GA10959@redhat.com> References: <4FFE7C1F.7080702@gmx.net> <20120712194432.GA2592@local> <20120712231632.GC9317@redhat.com> <1342166955.6607.5.camel@blech> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Hans J. Koch" , Andreas Schallenberg , "linux-kernel@vger.kernel.org" , Greg Kroah-Hartman , kvm@vger.kernel.org To: Dominic Eschweiler Return-path: Content-Disposition: inline In-Reply-To: <1342166955.6607.5.camel@blech> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Fri, Jul 13, 2012 at 10:09:15AM +0200, Dominic Eschweiler wrote: > Am Freitag, den 13.07.2012, 02:16 +0300 schrieb Michael S. Tsirkin: > > My concern was people will ask for more and more stuff that pci > > sysfs already has. > > If we do add these is there a way to not duplicate code from pci? > > I have some concerns about the placing for the BAR mapping code inside > the kernel. The point is, that sysfs currently makes it possible to map > BARs of all card which are handled by any driver. This is fine in case > of UIO, because it is intended that a user-space program maps BARs, but > it is also possible to map BARs that are already handle by a kernel > driver. It i therefore possible to jam the system by confusing sysfs > entries. > > I don't know which implications this has, but I would move the BAR > mapping capabilities completely to UIO. This should ensure that only > BARs can be mapped, which are handled by UIO and no other kernel-space > driver. Could you give an example of the problem? How do you bind both UIO and another driver to the same device? -- MST