From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@redhat.com>
Subject: Re: [RFC v1] Add declarations for hierarchical memory
 region API
Date: Fri, 20 May 2011 12:18:58 +0300
Message-ID: <4DD63202.7020502@redhat.com>
References: <1305814352-15044-1-git-send-email-avi@redhat.com>	
	<1305814352-15044-2-git-send-email-avi@redhat.com>
	<1305832022.3100.5.camel@x201>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org
To: Alex Williamson <alex.williamson@redhat.com>
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <1305832022.3100.5.camel@x201>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: </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>
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
List-Id: 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.