From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: PCI Passthrough ARM Design : Draft1
Date: Fri, 26 Jun 2015 09:52:48 -0400
Message-ID: <20150626135248.GD2341@l.oracle.com>
References: <1435234888.32500.80.camel@citrix.com>
	<20150625172647.GB2470@x230.dumpdata.com>
	<558CB3DE.7000004@caviumnetworks.com>
	<1435303946.17598.41.camel@citrix.com>
	<558D123D.50205@caviumnetworks.com>
	<1435309787.32500.151.camel@citrix.com>
	<558D3E1C.8000304@caviumnetworks.com>
	<1435322468.32500.184.camel@citrix.com>
	<20150626132842.GA2106@l.oracle.com>
	<1435326458.32500.185.camel@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <1435326458.32500.185.camel@citrix.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: Ian Campbell <ian.campbell@citrix.com>
Cc: Vijay Kilari <vijay.kilari@gmail.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Prasun Kapoor <Prasun.kapoor@caviumnetworks.com>, "Kumar,
	Vijaya" <Vijaya.Kumar@caviumnetworks.com>, Manish Jaggi <mjaggi@caviumnetworks.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Julien Grall <julien.grall@citrix.com>, Stefano Stabellini <stefano.stabellini@citrix.com>, "Kulkarni,
	Ganapatrao" <Ganapatrao.Kulkarni@caviumnetworks.com>, Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
List-Id: xen-devel@lists.xenproject.org

On Fri, Jun 26, 2015 at 02:47:38PM +0100, Ian Campbell wrote:
> On Fri, 2015-06-26 at 09:28 -0400, Konrad Rzeszutek Wilk wrote:
> > I would advocate a more dynamic idea of GUEST_MMIO_* so that the toolstack
> > can allocate those with headroom. Perhaps stash it at the far far end
> > of the guest accessible memory? But that would require an 64-bit capable
> > OS which might not work for all use-cases (where you want a 32-bit OS).
> 
> I'd be incline to define two areas, one under 4GB but limited in size
> and the other above and to decide which to used based on $factors-tbd

+1