From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33625) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHOqq-00087S-C1 for qemu-devel@nongnu.org; Mon, 27 Jun 2016 01:12:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bHOqm-0006Xp-Ak for qemu-devel@nongnu.org; Mon, 27 Jun 2016 01:12:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54620) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHOqm-0006Xg-2S for qemu-devel@nongnu.org; Mon, 27 Jun 2016 01:12:48 -0400 Date: Sun, 26 Jun 2016 23:12:45 -0600 From: Alex Williamson Message-ID: <20160626231245.6cd83a62@t450s.home> In-Reply-To: References: <20160615154203.32658.82724.stgit@gimli.home> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Alexey Kardashevskiy 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 Mon, 27 Jun 2016 14:46:12 +1000 Alexey Kardashevskiy wrote: > 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. The only file I maintain from this series is just minor collateral from the api change. I'll therefore redirect this question to Paolo, but I'm happy to pull it through my tree with his ack. 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(-) > >