From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [v4][PATCH 4/9] tools:libxc: check if mmio BAR is
 out of RMRR mappings
Date: Wed, 27 Aug 2014 03:20:35 +0100
Message-ID: <1409106035.28009.84.camel@citrix.com>
References: <1408702186-24432-1-git-send-email-tiejun.chen@intel.com>
	<1408702186-24432-5-git-send-email-tiejun.chen@intel.com>
	<1409085374.28009.37.camel@citrix.com> <53FD3891.5020202@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <53FD3891.5020202@intel.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: "Chen, Tiejun" <tiejun.chen@intel.com>
Cc: kevin.tian@intel.com, stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, JBeulich@suse.com, yang.z.zhang@intel.com
List-Id: xen-devel@lists.xenproject.org

On Wed, 2014-08-27 at 09:46 +0800, Chen, Tiejun wrote:
> On 2014/8/27 4:36, Ian Campbell wrote:
> > On Fri, 2014-08-22 at 18:09 +0800, Tiejun Chen wrote:
> >
> >> +    /* We should check if mmio range is out of RMRR mapping.
> >> +     *
> >> +     * Assume we have one entry if not enough we'll expand.
> >> +     */
> >
> > The usual approach with such hypervisor interfaces (which I suppose
> > xc_reserved_device_memory_map turns into) is to first call it with NULL
> > to get the required size and then allocate a suitable buffer and call a
> > second time.
> 
> Ofentimes, RMRR should be rare with one or two entries, even zero.

It's not clear to me what number you are saying is the norm here.

Even if some N is common today what guarantee is there that N won't grow
or shrink with the next generation of systems?

>  So I 
> think its reasonable to start posting one entry since this can cover 
> such a scenario the platform really owns one entry.

Making the call twice is not terribly expensive (nor is this a hot path)
and it allows you to avoid the reallocation and recall and the twisty
error handling structure which that implies.

Ian.