[Libvir] [PATCH] Fix dom0 maxmem display for memmax not set case

Hi, This patch intends to fix dom0 maxmem display. If we do NOT set maximum memory, max_pages (in Xen) are set maximum value(0xFFFFFFFF). This display confuses user. For x86 cases, following data are shown on "virsh dominfo 0" (please case 4kb page size This case max_pages x 4 is output). Max memory: 4294967292 kB This patch fix as follows Max memory: no limit (This comment is taken from xentop :-)) This problem is already cared on xentop (Xen performance tool). Signed-off-by: Atsushi SAKAI <sakaia@jp.fujitsu.com> Thanks Atsushi SAKAI diff -urpN libvirt.orig/src/virsh.c libvirt/src/virsh.c --- libvirt.orig/src/virsh.c 2007-03-09 22:44:24.000000000 +0900 +++ libvirt/src/virsh.c 2007-03-15 20:13:04.000000000 +0900 @@ -1186,8 +1186,13 @@ cmdDominfo(vshControl * ctl, vshCmd * cm vshPrint(ctl, "%-15s %.1lfs\n", _("CPU time:"), cpuUsed); } - vshPrint(ctl, "%-15s %lu kB\n", _("Max memory:"), + if (info.maxMem != UINT_MAX) + vshPrint(ctl, "%-15s %lu kB\n", _("Max memory:"), info.maxMem); + else + vshPrint(ctl, "%-15s %-15s\n", _("Max memory:"), + _("no limit")); + vshPrint(ctl, "%-15s %lu kB\n", _("Used memory:"), info.memory); diff -urpN libvirt.orig/src/xen_internal.c libvirt/src/xen_internal.c --- libvirt.orig/src/xen_internal.c 2007-03-15 16:43:16.000000000 +0900 +++ libvirt/src/xen_internal.c 2007-03-15 19:38:17.000000000 +0900 @@ -1598,7 +1598,9 @@ xenHypervisorGetDomInfo(virConnectPtr co */ info->cpuTime = XEN_GETDOMAININFO_CPUTIME(dominfo); info->memory = XEN_GETDOMAININFO_TOT_PAGES(dominfo) * kb_per_pages; - info->maxMem = XEN_GETDOMAININFO_MAX_PAGES(dominfo) * kb_per_pages; + info->maxMem = XEN_GETDOMAININFO_MAX_PAGES(dominfo); + if(info->maxMem != UINT_MAX) + info->maxMem *= kb_per_pages; info->nrVirtCpu = XEN_GETDOMAININFO_CPUCOUNT(dominfo); return (0); }

On Thu, Mar 15, 2007 at 09:36:12PM +0900, Atsushi SAKAI wrote:
Hi,
This patch intends to fix dom0 maxmem display.
If we do NOT set maximum memory, max_pages (in Xen) are set maximum value(0xFFFFFFFF). This display confuses user. For x86 cases, following data are shown on "virsh dominfo 0" (please case 4kb page size This case max_pages x 4 is output). Max memory: 4294967292 kB This patch fix as follows Max memory: no limit (This comment is taken from xentop :-))
This problem is already cared on xentop (Xen performance tool).
Signed-off-by: Atsushi SAKAI <sakaia@jp.fujitsu.com>
Right, this makes sense ! Thanks for catching this, I applied and commited your patch to CVS. Just one tiny thing if you could provide patches as attachments to mails instead of inline, this makes things a bit more easy and reliable from my point of vue :-) thanks a lot ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

Hi, Daniel I resend it. I like patch in attach file way (like Xen not Linux). Thanks Atsushi SAKAI Daniel Veillard <veillard@redhat.com> wrote:
commited your patch to CVS. Just one tiny thing if you could provide patches as attachments to mails instead of inline, this makes things a bit more easy and reliable from my point of vue :-)

On Fri, Mar 16, 2007 at 10:03:31AM +0900, Atsushi SAKAI wrote:
Hi, Daniel
I resend it.
Well that wasn't needed, I already had applied it :-)
I like patch in attach file way (like Xen not Linux).
Right that way, I prefer doing it that way because attachement are usually left intact by various mail agents, get a full URL in mail archives https://www.redhat.com/archives/libvir-list/2007-March/binLZNUpi9LpN.bin in your case, and they are easier to save from my mail agent (mutt) than the email content itself :-) thanks ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (2)
-
Atsushi SAKAI
-
Daniel Veillard