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] Re: [PATCH][HVM] fix VNIF restore failure on HVMguestwit

To: Steven Hand <Steven.Hand@xxxxxxxxxxxx>, Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH][HVM] fix VNIF restore failure on HVMguestwith heavy workload
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Fri, 13 Apr 2007 10:42:19 +0100
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Zhao, Fan" <fan.zhao@xxxxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>
Delivery-date: Fri, 13 Apr 2007 02:41:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <E1Hc4Nt-0001kG-00@xxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acd9sAcWRYoSX+mjEdu6zAAX8io7RQ==
Thread-topic: [Xen-devel] Re: [PATCH][HVM] fix VNIF restore failure on HVMguestwith heavy workload
User-agent: Microsoft-Entourage/
On 12/4/07 19:51, "Steven Hand" <Steven.Hand@xxxxxxxxxxxx> wrote:

>> Any reason not to have the balloon driver write back to Xenstore if it's
>> used in this way.  Or is it just waiting for a patch to do that?
> You also need xend to watch the node and update its internal structures,
> but otherwise that'd be fine.

We're not sure if this is even sensible in all cases. Should an admin memory
setting be overridable by a setting derived from the guest itself?

One sensible middle ground might be for the balloon driver to ignore the
memory-target field in xenstore if the balloon target has ever been
specified via /proc/xen/balloon. This would indicate that the guest is
taking control for its own memory setting and is a simple resolution of the
conflict over whose setting takes precedence. This might be good enough for
those people who would like us to keep the /proc/xen/balloon method (I was
considering killing it off entirely) -- I suspect people either want to
control their guest memory settings inside the guests *or* via 'xm mem-set':
not both.

 -- Keir

Xen-devel mailing list