From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56752) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHORG-0005En-8w for qemu-devel@nongnu.org; Mon, 27 Jun 2016 00:46:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bHORC-0001rY-45 for qemu-devel@nongnu.org; Mon, 27 Jun 2016 00:46:25 -0400 Received: from mail-pa0-x243.google.com ([2607:f8b0:400e:c03::243]:34903) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHORB-0001r8-Ok for qemu-devel@nongnu.org; Mon, 27 Jun 2016 00:46:22 -0400 Received: by mail-pa0-x243.google.com with SMTP id hf6so14328979pac.2 for ; Sun, 26 Jun 2016 21:46:20 -0700 (PDT) References: <20160615154203.32658.82724.stgit@gimli.home> From: Alexey Kardashevskiy Message-ID: Date: Mon, 27 Jun 2016 14:46:12 +1000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/2] memory/intel_iommu: Generate error for incompatible usage List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: qemu-devel@nongnu.org, mst@redhat.com, bd.aviv@gmail.com, peterx@redhat.com, marcel@redhat.com, pbonzini@redhat.com, david@gibson.dropbear.id.au On 16/06/16 11:43, Alexey Kardashevskiy wrote: > On 16/06/16 01:56, Alex Williamson wrote: >> VT-d emulation is currently incompatible with device assignment due >> to intel_iommu's lack of support for memory_region_notify_iommu(). >> Alexey has proposed a nice addition to the MemoryRegionIOMMUOps >> structure that adds callbacks when the first iommu notifier is >> registered and the last is removed. For POWER this will allow them >> to switch the view of the iommu depending on whether anyone in >> userspace is watching. For VT-d I expect that eventually we'll use >> these callbacks to enable and disable code paths so that we avoid >> notifier overhead when there are no registered notifiy-ees. For now, >> we don't support calling memory_region_notify_iommu(), so this >> signals an incompatible hardware configuration. If we choose to make >> CM=0 a user selectable option, something like this might continue to >> be useful if we only support notifies via invalidations rather than >> full VT-d data structure shadowing. >> >> Even though we're currently working on enabling users like vfio-pci >> with VT-d, I believe this is correct for the current state of things. >> We might even want to consider this stable for v2.6.x so that >> downstreams pick it up to avoid incompatible configurations. >> >> Alexey, I hope I'm not stepping on your toes by extracting this >> from your latest patch series. Please let us know whether you >> approve. Thanks, > > I am totally fine with either way of accepting my patches, after all the > idea was yours, I just put it in the code :) Alex, when are you planning on sending pull request with this patch? I am asking as I'd prefer to respin "spapr_pci/spapr_pci_vfio: Support Dynamic DMA" on top of it (assuming David rebases his queue on top of it) and avoid doing unnecessary work. Thanks. > > >> >> Alex >> >> --- >> >> Alex Williamson (1): >> intel_iommu: Throw hw_error on notify_started >> >> Alexey Kardashevskiy (1): >> memory: Add MemoryRegionIOMMUOps.notify_started/stopped callbacks >> >> >> hw/i386/intel_iommu.c | 12 ++++++++++++ >> hw/vfio/common.c | 5 +++-- >> include/exec/memory.h | 8 +++++++- >> memory.c | 10 +++++++++- >> 4 files changed, 31 insertions(+), 4 deletions(-) -- Alexey