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
approach.
Thanks,
-b
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.
Thanks,
Keir
--
------------------------------------------------------------------------
Ben Thomas Virtual Iron Software
bthomas@xxxxxxxxxxxxxxx Tower 1, Floor 2
978-849-1214 900 Chelmsford Street
Lowell, MA 01851
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home