From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58180) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WX0qf-000837-5S for qemu-devel@nongnu.org; Mon, 07 Apr 2014 00:08:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WX0qW-00056y-HI for qemu-devel@nongnu.org; Mon, 07 Apr 2014 00:07:53 -0400 Received: from mail-pa0-f47.google.com ([209.85.220.47]:44869) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WX0qW-00056e-Bt for qemu-devel@nongnu.org; Mon, 07 Apr 2014 00:07:44 -0400 Received: by mail-pa0-f47.google.com with SMTP id lj1so6066149pab.6 for ; Sun, 06 Apr 2014 21:07:43 -0700 (PDT) Message-ID: <53422489.4060206@ozlabs.ru> Date: Mon, 07 Apr 2014 14:07:37 +1000 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <1394603550-11556-1-git-send-email-aik@ozlabs.ru> <1394603550-11556-9-git-send-email-aik@ozlabs.ru> <533D5159.7040103@suse.com> In-Reply-To: <533D5159.7040103@suse.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 08/11] spapr-iommu: add SPAPR VFIO IOMMU device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf , Alex Williamson Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Alexander Graf On 04/03/2014 11:17 PM, Alexander Graf wrote: > > On 12.03.14 06:52, Alexey Kardashevskiy wrote: >> This adds SPAPR VFIO IOMMU device in order to support DMA operations >> for VFIO devices. > > Sorry if this has been mentioned before, but why exactly do you need a > separate IOMMU for VFIO? Couldn't the existing IOMMU backend drive things? Well... Since I started VFIO on SPAPR, the emulated and VFIO IOMMU became almost the same thing and I'll rework that too before I post things again. However one difference still remains - IOMMU for emulated PCI and VIO keeps a TCE table (allocated in QEMU or mmap'ed from the host kernel) and VFIO IOMMU works with the table which is allocated and owned by the host kernel. Since TCE tables are used only by devices, the IOMMU translation callback is never called by VFIO devices and that's ok and I checked - it works. So I either need a property in the IOMMU device to tell it is TCE table and MemoryRegionIOMMUOps::translate() are required. Or a new IOMMU device class. What to choose? Oh. btw. There is H_GET_TCE now which I have to implement for VFIO :( This will never ever end. -- Alexey