From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:32779) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1mdM-0007w3-Fx for qemu-devel@nongnu.org; Thu, 08 Sep 2011 17:59:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1mdL-0002po-DL for qemu-devel@nongnu.org; Thu, 08 Sep 2011 17:59:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38048) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1mdL-0002pi-1Y for qemu-devel@nongnu.org; Thu, 08 Sep 2011 17:59:43 -0400 From: Alex Williamson Date: Thu, 08 Sep 2011 14:54:58 -0700 In-Reply-To: <3B2BACC2-C445-4F32-8E21-19FD28FF2CDC@suse.de> References: <20110901194915.2391.97400.stgit@s20.home> <3B2BACC2-C445-4F32-8E21-19FD28FF2CDC@suse.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Message-ID: <1315519006.2662.11.camel@x201.home> Mime-Version: 1.0 Subject: Re: [Qemu-devel] [RFC PATCH 0/5] VFIO-NG group/device/iommu framework List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: aafabbri@cisco.com, aik@au1.ibm.com, kvm@vger.kernel.org, pmac@au1.ibm.com, joerg.roedel@amd.com, qemu-devel@nongnu.org, dwg@au1.ibm.com, chrisw@sous-sol.org, B08248@freescale.com, iommu@lists.linux-foundation.org, avi@redhat.com, linux-pci@vger.kernel.org, B07421@freescale.com, benve@cisco.com On Wed, 2011-09-07 at 13:58 +0200, Alexander Graf wrote: > On 01.09.2011, at 21:50, Alex Williamson wrote: > > > Trying to move beyond talking about how VFIO should work to > > re-writing the code. This is pre-alpha, known broken, will > > probably crash your system but it illustrates some of how > > I see groups, devices, and iommus interacting. This is just > > the framework, no code to actually support user space drivers > > or device assignment yet. > > > > The iommu portions are still using the "FIXME" PCI specific > > hooks. Once Joerg gets some buy-in on his bus specific iommu > > patches, we can move to that. > > > > The group management is more complicated than I'd like and > > you can get groups into a bad state by killing the test program > > with devices/iommus open. The locking is overly simplistic. > > But, it's a start. Please make constructive comments and > > suggestions. Patches based on v3.0. Thanks, > > Looks pretty reasonable to me so far, but I guess we only know for sure once we have non-PCI implemented and working with this scheme as well. > Btw I couldn't find the PCI BAR regions mmaps and general config space exposure. Where has that gone? I ripped it out for now just to work on the group/device/iommu framework. I didn't see a need to make a functional RFC just to get some buy-in on the framework. Thanks, Alex