From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [RFC Patch] Support for making an E820 PCI hole in toolstack (xl + xm) Date: Mon, 15 Nov 2010 13:15:44 -0500 Message-ID: <20101115181544.GA8840@dumpdata.com> References: <20101115170302.GA7414@dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Jeremy Fitzhardinge , xen-devel@lists.xensource.com, bruce.edge@gmail.com, gianni.tedesco@citrix.com, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org > > 1). Did not work for me - I am not sure why but I had the hardest time do > > hypervisor_populate_physmap - it would just hang the guest. > > For a PV guest you don't need to do any alloc/free/move memory hypercalls. > You rewrite your own p2m to relocate mfns where you want them in pfn space. > Then some hypercalls just to update the m2p array to match. Ok, I can play with that see what fun/havoc I can create. > > > 2). It is much simple to parse the E820 in the Linux kernel than actually > > creating new E820 entries in the kernel (hypercall), making a bunch of > > hypervisor calls that unmap, then remap the space, filling out the P2M > > with INVALID_MFN, and doing all of that before the "real" Linux kernel > > actually starts (all would have to be done in xen_start_kernel). > > I have a sinking feeling tha the upstream community would not like it > > this that much. > > Well it is all quite Xen specific, so I'm surprised. Oh, there was another reason that I so obvious that I completly forgot. DomU has no idea where the host PCI hole starts. In most cases it is at 3GB (or even further up - 3.5GB), but a quick look for 'Allocating PCI resources starting at' at Google shows that there are some that start at 1.2G.