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


[Xen-devel] RE: Why p2m allocation is from hap or shadow preallocated me

To: "Tim Deegan" <Tim.Deegan@xxxxxxxxxxxxx>
Subject: [Xen-devel] RE: Why p2m allocation is from hap or shadow preallocated memory?
From: "Li, Xin B" <xin.b.li@xxxxxxxxx>
Date: Tue, 7 Aug 2007 16:43:56 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 07 Aug 2007 01:41:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070807082857.GA26711@xxxxxxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <B30DA1341B0CFA4893EF8A36B40B5C5D017D4B95@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20070807082857.GA26711@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcfYzT2SN8vVhGL/SYWzFGy3ANASSwAAZ0CQ
Thread-topic: Why p2m allocation is from hap or shadow preallocated memory?
>Hi Xin,
>At 15:54 +0800 on 07 Aug (1186502042), Li, Xin B wrote:
>> And can we make p2m memory allocation from domain heap directly?
>We shouldn't pull from the domheap directly because it's not accounted
>for.  This was a problem with the old shadow code, which just kept
>pulling un-owned pages from the domheap until it (or sometimes 
>Xen) fell
>over.  The shadow memory allocation is explicitly separate and can be
>accounted to the guest that's using it and tracked by the tools.

Then how about having a p2m preallocation pool seperately?

>There are still a number of places, particularly in the HVM platform
>code, where unaccounted domheap memory is used for per-domain or
>per-vcpu structures, but at least they're usually small (~1 page) and
>static (no need to allocate more at run-time and have domains blow up
>unpredictably, and reasonable confidence that domheap won't drain away
>when we're not looking).
>Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, XenSource UK Limited
>Registered office c/o EC2Y 5EB, UK; company number 05334508

Xen-devel mailing list