From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33578) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNA4b-0006mS-B6 for qemu-devel@nongnu.org; Thu, 19 May 2011 16:43:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QNA4a-00087J-FE for qemu-devel@nongnu.org; Thu, 19 May 2011 16:43:57 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:36135) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNA4a-000877-Ci for qemu-devel@nongnu.org; Thu, 19 May 2011 16:43:56 -0400 Received: by gyg4 with SMTP id 4so1247438gyg.4 for ; Thu, 19 May 2011 13:43:55 -0700 (PDT) Message-ID: <4DD580FD.2030409@codemonkey.ws> Date: Thu, 19 May 2011 15:43:41 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1305814352-15044-1-git-send-email-avi@redhat.com> <1305814352-15044-2-git-send-email-avi@redhat.com> In-Reply-To: <1305814352-15044-2-git-send-email-avi@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 05/19/2011 09:12 AM, 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; > + /* If true, unaligned accesses are supported. Otherwise unaligned > + * accesses throw machine checks. > + */ > + bool unaligned; > + } valid; Under what circumstances would this be used? The behavior of devices that receive non-natural accesses varies wildly. For PCI devices, invalid accesses almost always return ~0. I can't think of a device where an MCE would occur. Regards, Anthony Liguori