This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [RFC Patch] Support for making an E820 PCI hole in tools

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC Patch] Support for making an E820 PCI hole in toolstack (xl + xm)
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Mon, 15 Nov 2010 11:30:51 -0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxx>, bruce.edge@xxxxxxxxx, gianni.tedesco@xxxxxxxxxx, stefano.stabellini@xxxxxxxxxxxxx
Delivery-date: Mon, 15 Nov 2010 11:31:57 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20101115181544.GA8840@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20101115170302.GA7414@xxxxxxxxxxxx> <C9072307.A021%keir@xxxxxxx> <20101115181544.GA8840@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101027 Fedora/3.1.6-1.fc13 Lightning/1.0b3pre Thunderbird/3.1.6
On 11/15/2010 10:15 AM, Konrad Rzeszutek Wilk wrote:
>>>  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.

Yes, that's the main reason I think it should be in the toolstack.  The
domain doesn't know whether the PCI hole is necessary or not, and its
too early for it to poke around in xenstore to look for passed devices
or anything.  It could conservatively always reserve a 1G hole at 3G,
but that seems too pessimistic and is a waste of sub-4G adress space
which it might otherwise have use for.

If the toolstack can tell it where to make the hole by editing the E820,
then the dom0 and domU cases are very similar.

The question of whether all the pages given by the builder to the domain
should be distributed over the E820 RAM ranges, or should just be
considered ballooned out of the holes (which is what currently happens)
is pretty much orthogonal.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>