From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35004) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIHqS-0003VO-EQ for qemu-devel@nongnu.org; Wed, 29 Jun 2016 11:56:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bIHqP-0005LZ-Qe for qemu-devel@nongnu.org; Wed, 29 Jun 2016 11:56:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52353) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIHqP-0005L5-Hz for qemu-devel@nongnu.org; Wed, 29 Jun 2016 11:56:05 -0400 Date: Wed, 29 Jun 2016 09:56:01 -0600 From: Alex Williamson Message-ID: <20160629095601.0ae08f7d@t450s.home> In-Reply-To: <33a19cf3-13dc-6ce0-7a68-8cfdef7f0357@redhat.com> References: <20160615154203.32658.82724.stgit@gimli.home> <20160628084924.43566423@t450s.home> <33a19cf3-13dc-6ce0-7a68-8cfdef7f0357@redhat.com> 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: Paolo Bonzini Cc: mst@redhat.com, qemu-devel@nongnu.org, aik@ozlabs.ru, bd.aviv@gmail.com, peterx@redhat.com, marcel@redhat.com, david@gibson.dropbear.id.au On Wed, 29 Jun 2016 12:53:39 +0200 Paolo Bonzini wrote: > On 28/06/2016 16:49, Alex Williamson wrote: > > Paolo & Michael, > > > > Any comments on this series? I think we need Paolo's ack for the memory > > changes and either of your ack for hw/i386/. I'm happy to pull this > > through my tree with your approval though. Thanks, > > I think I already acked the callbacks, in any case the patches look good. Hmm, I can't find any evidence of that and I'm not terribly comfortable inferring an Acked-by where it is not explicitly given. Can you send a formal sign-off or point me to where I can find the one you're thinking of? Thanks, Alex > > On Wed, 15 Jun 2016 09:56:03 -0600 > > 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, > >> > >> 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(-) > >