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] [PATCH] - return error when appropriate from increase_me

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] - return error when appropriate from increase_memory_reservation
From: Ben Thomas <bthomas@xxxxxxxxxxxxxxx>
Date: Thu, 20 Apr 2006 15:41:58 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 20 Apr 2006 12:42:21 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <a5d2e90866045115abc4cce9241b4f33@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/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: <4447CD27.6080808@xxxxxxxxxxxxxxx> <a5d2e90866045115abc4cce9241b4f33@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
You're right - I was fixing this too quickly. The issue I was
encountering is that xc_domain_memory_increase_reservation
may return 0(success) when no pages have been reserved.  Put
this in a loop and you get, well, interesting results.

There are several possible solutions for this, all done at
that level.  However, it isn't clear to me at this moment
what the best and most correct solution would be. So, I'm
going to put this off for now and continue to use a different


Keir Fraser wrote:

On 20 Apr 2006, at 19:04, Ben Thomas wrote:

This patch fixes a case in increasing a memory reservation where you
do not get the pages nor do you get an error.  While an argument might
be made that checking the page count independently is workable, it
does seem reasonable to have the operation return a failure in the
cases where it doesn't do what was asked. Right now, it mostly returns
the correct status.  This patch just adds another instance of this.

No. In cases where it fails it does not undo its partial work. The current return lets the caller know how much work was done so that appropriate action can be taken. The callers need fixing -- there aren't that many. Only increase_reservation or populate_physmap can fail, unless the caller is buggy, so they are the only ones that really need fixing. The others should probably BUG_ON() or assert or print an error in the caller though.

And, while-I-was-there, I've been generating linker maps for qemu in
my own builds. It's harmless, until you need it and then it's valuable.
Tweak the Makefile to create the map.

I'll take that as a separate patch.


Ben Thomas                                         Virtual Iron Software
bthomas@xxxxxxxxxxxxxxx                            Tower 1, Floor 2
978-849-1214                                       900 Chelmsford Street
                                                   Lowell, MA 01851

Xen-devel mailing list

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