From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54694) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNLrM-0001tr-RZ for qemu-devel@nongnu.org; Fri, 20 May 2011 05:19:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QNLrL-00008W-TU for qemu-devel@nongnu.org; Fri, 20 May 2011 05:19:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21438) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNLrL-00008O-HB for qemu-devel@nongnu.org; Fri, 20 May 2011 05:19:03 -0400 Message-ID: <4DD63202.7020502@redhat.com> Date: Fri, 20 May 2011 12:18:58 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1305814352-15044-1-git-send-email-avi@redhat.com> <1305814352-15044-2-git-send-email-avi@redhat.com> <1305832022.3100.5.camel@x201> In-Reply-To: <1305832022.3100.5.camel@x201> Content-Type: text/plain; charset=UTF-8; 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: Alex Williamson Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 05/19/2011 10:07 PM, Alex Williamson wrote: > 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. > > > + /* 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? As far as I can tell, yes. > This might > be easier to describe as a bitmap of supported power of 2 access sizes. This is uglier to initialize. However we can provide #defines for common use (MEM_ACCESS_BYTE_TO_LONG, MEM_ACCESS_LONG). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.