From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:44971)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <alex.williamson@redhat.com>) id 1ZEjXG-0006CQ-OX
	for qemu-devel@nongnu.org; Mon, 13 Jul 2015 15:37:07 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <alex.williamson@redhat.com>) id 1ZEjXD-0004kq-Fn
	for qemu-devel@nongnu.org; Mon, 13 Jul 2015 15:37:06 -0400
Message-ID: <1436816220.1391.393.camel@redhat.com>
From: Alex Williamson <alex.williamson@redhat.com>
Date: Mon, 13 Jul 2015 13:37:00 -0600
In-Reply-To: <1436799381-16150-1-git-send-email-aik@ozlabs.ru>
References: <1436799381-16150-1-git-send-email-aik@ozlabs.ru>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC PATCH qemu v2 0/5] vfio: SPAPR IOMMU v2
 (memory preregistration support)
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: Michael Roth <mdroth@linux.vnet.ibm.com>, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, David Gibson <david@gibson.dropbear.id.au>

On Tue, 2015-07-14 at 00:56 +1000, Alexey Kardashevskiy wrote:
> Here are few patches to prepare an existing listener for handling memory
> preregistration for SPAPR guests running on POWER8.
> 
> This used to be a part of DDW patchset but now is separated as requested.
> I left versions in changelog of 5/5 for convenience.
> 
> Please comment, specifically about how many memory listeners we want to
> have in VFIO.
> 
> The existing listener listens on PCI address space which in fact is RAM
> on x86 but is not on sPAPR. Memory preregistration requires listening
> on RAM for sPAPR too. Having a listener without a filter is tricky as it
> will be notified on VIO address spaces too so having more that one listener
> makes some sense. Any input is welcome.

What I think you're doing here is using the same core memory listener
functions wrapped in separate memory listeners so that you can look only
at the address spaces you're interested in, iommu vs ram.  I think that
largely achieves the consolidation I was looking for.  I don't
particularly care how many different ways you register memory listeners,
but I don't want to have a new set of memory listener callbacks that do
largely the same thing as the existing callback.  Thanks,

Alex