From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41430) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN8Ys-00082x-Hd for qemu-devel@nongnu.org; Thu, 19 May 2011 15:07:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN8Yr-0001lH-4U for qemu-devel@nongnu.org; Thu, 19 May 2011 15:07:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14347) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN8Yq-0001kv-PL for qemu-devel@nongnu.org; Thu, 19 May 2011 15:07:05 -0400 From: Alex Williamson In-Reply-To: <1305814352-15044-2-git-send-email-avi@redhat.com> References: <1305814352-15044-1-git-send-email-avi@redhat.com> <1305814352-15044-2-git-send-email-avi@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 19 May 2011 13:07:02 -0600 Message-ID: <1305832022.3100.5.camel@x201> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v1] Add declarations for hierarchical memory region API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On Thu, 2011-05-19 at 10:12 -0400, Avi Kivity wrote: > The memory API separates the attributes of a memory region (its size, how > reads or writes are handled, dirty logging, and coalescing) from where it > is mapped and whether it is enabled. This allows a device to configure > a memory region once, then hand it off to its parent bus to map it according > to the bus configuration. > > Hierarchical registration also allows a device to compose a region out of > a number of sub-regions with different properties; for example some may be > RAM while others may be MMIO. > > Signed-off-by: Avi Kivity > --- > memory.h | 142 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 142 insertions(+), 0 deletions(-) > create mode 100644 memory.h > > diff --git a/memory.h b/memory.h > new file mode 100644 > index 0000000..77c5951 > --- /dev/null > +++ b/memory.h > @@ -0,0 +1,142 @@ > +#ifndef MEMORY_H > +#define MEMORY_H > + > +#include > +#include > +#include "qemu-common.h" > +#include "cpu-common.h" > +#include "targphys.h" > +#include "qemu-queue.h" > + > +typedef struct MemoryRegionOps MemoryRegionOps; > +typedef struct MemoryRegion MemoryRegion; > + > +/* > + * Memory region callbacks > + */ > +struct MemoryRegionOps { > + /* Read from the memory region. @addr is relative to @mr; @size is > + * in bytes. */ > + uint64_t (*read)(MemoryRegion *mr, > + target_phys_addr_t addr, > + unsigned size); > + /* Write to the memory region. @addr is relative to @mr; @size is > + * in bytes. */ > + void (*write)(MemoryRegion *mr, > + target_phys_addr_t addr, > + uint64_t data, > + unsigned size); > + /* Guest-visible constraints: */ > + struct { > + /* If nonzero, specify bounds on access sizes beyond which a machine > + * check is thrown. > + */ > + unsigned min_access_size; > + unsigned max_access_size; Do we always support all access sizes between min and max? This might be easier to describe as a bitmap of supported power of 2 access sizes. Thanks, Alex