From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43316) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJmFb-0002M2-Jd for qemu-devel@nongnu.org; Thu, 04 Oct 2012 10:19:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TJmEa-00006Q-5Q for qemu-devel@nongnu.org; Thu, 04 Oct 2012 10:18:07 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:60913) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TJmEZ-000068-RK for qemu-devel@nongnu.org; Thu, 04 Oct 2012 10:17:04 -0400 Received: by mail-ob0-f173.google.com with SMTP id wc18so471522obb.4 for ; Thu, 04 Oct 2012 07:17:03 -0700 (PDT) From: Anthony Liguori In-Reply-To: <506D4534.4090000@redhat.com> References: <1349280245-16341-1-git-send-email-avi@redhat.com> <506D4534.4090000@redhat.com> Date: Thu, 04 Oct 2012 09:16:59 -0500 Message-ID: <878vbmiap0.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [RFC v1 00/22] Integrate DMA into the memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Avi Kivity Cc: Blue Swirl , "Michael S. Tsirkin" , qemu-devel@nongnu.org, liu ping fan Paolo Bonzini writes: > Il 03/10/2012 18:03, Avi Kivity ha scritto: >> Most of the work on the memory API focused on memory access targets - the memory regions >> and how they are composed into an address space. This patchset tackles the initator >> side of the question - how to originate accesses. >> >> The AddressSpace object, is exported to users and becomes the representation of an >> initiator. Each address space describes the paths from some point in the system >> (a device or cpu) to the devices reachable from that initiator. >> >> As an example, the API is used to support PCI_COMMAND_MASTER bit. > > Very nice, IMHO patches 1-18 should get in soon. They are a useful > cleanup on their own. Yup, other than a few minor cosmetics, the series is a very nice cleanup. I think this probably gets us fairly close to being able to write unit tests for the memory layer too which is really nice. Regards, Anthony Liguori > > Paolo > >> Avi Kivity (22): >> memory: rename 'exec-obsolete.h' >> vhost: use MemoryListener filtering to only monitor RAM address space >> kvm: use separate MemoryListeners for memory and I/O >> xen_pt: use separate MemoryListeners for memory and I/O >> memory: prepare AddressSpace for exporting >> memory: export AddressSpace >> memory: maintain a list of address spaces >> memory: provide defaults for MemoryListener operations >> memory: use new MEMORY_LISTENER_DEFAULT_OPS >> vfio: use new MEMORY_LISTENER_DEFAULT_OPS >> xen_pt: use new MEMORY_LISTENER_DEFAULT_OPS >> kvm: use new MEMORY_LISTENER_DEFAULT_OPS >> xen: use new MEMORY_LISTENER_DEFAULT_OPS >> memory: manage coalesced mmio via a MemoryListener >> memory: move address_space_memory and address_space_io out of memory >> core >> memory: move tcg flush into a tcg memory listener >> memory: use AddressSpace for MemoryListener filtering >> s390: avoid reaching into memory core internals >> memory: per-AddressSpace dispatch >> dma: make dma access its own address space >> pci: give each device its own address space >> pci: honor PCI_COMMAND_MASTER >> >> cputlb.c | 6 +- >> cputlb.h | 3 +- >> dma-helpers.c | 25 ++- >> dma.h | 17 +- >> exec-memory.h | 7 +- >> exec.c | 312 ++++++++++++++--------------------- >> hw/Makefile.objs | 5 +- >> hw/pci.c | 19 ++- >> hw/pci.h | 2 + >> hw/spapr_iommu.c | 3 +- >> hw/vfio_pci.c | 33 +--- >> hw/vhost.c | 5 +- >> hw/xen_pt.c | 49 +++--- >> hw/xen_pt.h | 1 + >> kvm-all.c | 107 +++++------- >> kvm-stub.c | 10 -- >> kvm.h | 2 - >> exec-obsolete.h => memory-internal.h | 30 +++- >> memory.c | 158 +++++++++++------- >> memory.h | 122 +++++++++++++- >> target-s390x/misc_helper.c | 2 +- >> xen-all.c | 45 +---- >> 22 files changed, 487 insertions(+), 476 deletions(-) >> rename exec-obsolete.h => memory-internal.h (87%) >>