From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51660) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbZAq-0001XW-RK for qemu-devel@nongnu.org; Fri, 16 Dec 2011 09:54:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbZAi-0004wh-4p for qemu-devel@nongnu.org; Fri, 16 Dec 2011 09:54:12 -0500 Received: from ch1ehsobe006.messaging.microsoft.com ([216.32.181.186]:35053 helo=ch1outboundpool.messaging.microsoft.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbZAi-0004uO-1G for qemu-devel@nongnu.org; Fri, 16 Dec 2011 09:54:04 -0500 Date: Fri, 16 Dec 2011 15:53:53 +0100 From: Joerg Roedel Message-ID: <20111216145353.GA29877@amd.com> References: <1323930340-24055-1-git-send-email-david@gibson.dropbear.id.au> <1323972307.2437.19.camel@x201.home> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <1323972307.2437.19.camel@x201.home> Subject: Re: [Qemu-devel] [RFC] Device isolation infrastructure v2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: chrisw@redhat.com, aik@ozlabs.ru, joro@8bytes.org, rusty@rustcorp.com.au, agraf@suse.de, qemu-devel@nongnu.org, B08248@freescale.com, iommu@lists.linux-foundation.org, scottwood@freescale.com, dwmw2@infradead.org, linux-kernel@vger.kernel.org, David Gibson On Thu, Dec 15, 2011 at 11:05:07AM -0700, Alex Williamson wrote: > Starting with it in the core and hand waving some future use that we > don't plan to implement right now seems like the wrong direction. I agree with Alex. First of all, I havn't seen any real vfio problem that can't be solved with the current approach, and it has the great advantage of simplicity. It doesn't require a re-implementation of the driver-core based on groups. I agree that we need some improvements to Alex' code for the dma-api layer to solve the problem with broken devices using the wrong requestor-id. But that can be done incrementally with the current (current == in the iommu-tree) approach implemented by Alex. I also think that all this does not belong into the driver core for two reasons: 1) The information for building the device groups is provided by the iommu-layer 2) The group information is provided to vfio by the iommu-api This makes the iommu-layer the logical point to place the grouping code. There are some sources outside of the iommu-layer that may influence grouping (like pci-quirks), but most of the job is done by the iommu-drivers. Thanks, Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632