[libvirt] getFreeMemory reporting incorrectly?
Hi, I'm currently running 2 CentOS 5.3 systems, one running Xen 3.3 and libvirt 0.6.4 (called node1) and the other running Xen 3.0.3 (stock CentOS) and libvirt 0.6.4 (called node2). The machines are practically identical except for the upgraded Xen installation. When using the libvirt-python module, I'm getting strange values from getFreeMemory() on the Xen 3.3 machine. See below: Xen 3.0.3: [root@node2 ~]# python Python 2.4.3 (#1, Jan 21 2009, 01:10:13) [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import libvirt conn = libvirt.open('xen:///') print(conn.getFreeMemory()) 268959744
Which is correct since there's approximately 256MB free. Now in the Xen 3.3 box: Xen 3.3: [root@node1 ~]# python Python 2.4.3 (#1, Jan 21 2009, 01:10:13) [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import libvirt conn = libvirt.open('xen:///') print(conn.getFreeMemory()) 576460752303423488
node1 should actually be reporting 0MB free, but instead I'm getting this huge number. It would be nice if I had this much memory though... Anybody else run into this? Hany
On Tue, Jun 09, 2009 at 06:00:29PM -0400, Hany Fahim wrote:
Hi, I'm currently running 2 CentOS 5.3 systems, one running Xen 3.3 and libvirt 0.6.4 (called node1) and the other running Xen 3.0.3 (stock CentOS) and libvirt 0.6.4 (called node2). The machines are practically identical except for the upgraded Xen installation. When using the libvirt-python module, I'm getting strange values from getFreeMemory() on the Xen 3.3 machine. See below:
Xen 3.0.3:
[root@node2 ~]# python Python 2.4.3 (#1, Jan 21 2009, 01:10:13) [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import libvirt conn = libvirt.open('xen:///') print(conn.getFreeMemory()) 268959744
Which is correct since there's approximately 256MB free. Now in the Xen 3.3 box:
Xen 3.3:
[root@node1 ~]# python Python 2.4.3 (#1, Jan 21 2009, 01:10:13) [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import libvirt conn = libvirt.open('xen:///') print(conn.getFreeMemory()) 576460752303423488
node1 should actually be reporting 0MB free, but instead I'm getting this huge number. It would be nice if I had this much memory though... Anybody else run into this?
For Xen we get the free memory information from a hypercall. I suspect that Xen 3.3 has changed the hypercall ABI in some way that is tripping up libvirt. Can you provide the output of 'xm info' for the 2 machines you have. Also what architecture are they ? Also can you check the per-node info with print(conn.getCellsFreeMemory(0,10)) Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Hey Daniel, Here is the output of 'xm list' from both machines: Xen 3.0.3 - This machine has 2GB total memory and should report 256MB free: [root@node2 ~]# xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 997 1 r----- 31431.7 test1 74 255 1 -b---- 2412.4 test2 73 511 1 -b---- 2434.3 Xen 3.3 - This machine has 3GB total memory and should report 0MB free: [root@node1 ~]# xm list Name ID Mem VCPUs State Time(s) Domain-0 0 2901 2 r----- 588.5 Both machines are i386 architecture. Here's the output of the getCellsFreeMemory call: Xen 3.0.3: [root@node2 ~]# python Python 2.4.3 (#1, Jan 21 2009, 01:10:13) [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import libvirt conn = libvirt.open('xen:///') print(conn.getCellsFreeMemory(0,10)) [268972032L]
Xen 3.3: [root@node1 ~]# python Python 2.4.3 (#1, Jan 21 2009, 01:10:13) [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import libvirt conn = libvirt.open('xen:///') print(conn.getCellsFreeMemory(0,10)) [576460752303423488L]
I appreciate the help. Hany On Wed, Jun 10, 2009 at 6:24 AM, Daniel P. Berrange <berrange@redhat.com>wrote:
Hi, I'm currently running 2 CentOS 5.3 systems, one running Xen 3.3 and
On Tue, Jun 09, 2009 at 06:00:29PM -0400, Hany Fahim wrote: libvirt
0.6.4 (called node1) and the other running Xen 3.0.3 (stock CentOS) and libvirt 0.6.4 (called node2). The machines are practically identical except for the upgraded Xen installation. When using the libvirt-python module, I'm getting strange values from getFreeMemory() on the Xen 3.3 machine. See below:
Xen 3.0.3:
[root@node2 ~]# python Python 2.4.3 (#1, Jan 21 2009, 01:10:13) [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import libvirt conn = libvirt.open('xen:///') print(conn.getFreeMemory()) 268959744
Which is correct since there's approximately 256MB free. Now in the Xen 3.3 box:
Xen 3.3:
[root@node1 ~]# python Python 2.4.3 (#1, Jan 21 2009, 01:10:13) [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import libvirt conn = libvirt.open('xen:///') print(conn.getFreeMemory()) 576460752303423488
node1 should actually be reporting 0MB free, but instead I'm getting this huge number. It would be nice if I had this much memory though... Anybody else run into this?
For Xen we get the free memory information from a hypercall. I suspect that Xen 3.3 has changed the hypercall ABI in some way that is tripping up libvirt. Can you provide the output of 'xm info' for the 2 machines you have. Also what architecture are they ?
Also can you check the per-node info with print(conn.getCellsFreeMemory(0,10))
Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/:| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org:| |: http://autobuild.org -o- http://search.cpan.org/~danberr/:| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Wed, Jun 10, 2009 at 07:28:51PM -0400, Hany Fahim wrote:
Hey Daniel, Here is the output of 'xm list' from both machines:
I wanted the 'xm info' output actually.... Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
My apologies. Here it is: Xen 3.3: [root@node1 ~]# xm info host : node1 release : 2.6.18-128.1.10.el5xen version : #1 SMP Thu May 7 11:51:15 EDT 2009 machine : i686 nr_cpus : 2 nr_nodes : 1 cores_per_socket : 1 threads_per_core : 2 cpu_mhz : 3391 hw_caps : bfebfbff:00000000:00000000:00000180:0000441d:00000000:00000000:00000000 virt_caps : total_memory : 3063 free_memory : 128 node_to_cpu : node0:0-1 node_to_memory : node0:128 xen_major : 3 xen_minor : 3 xen_extra : .1 xen_caps : xen-3.0-x86_32p xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xf5800000 xen_changeset : unavailable cc_compiler : gcc version 4.1.2 20071124 (Red Hat 4.1.2-42) cc_compile_by : root cc_compile_domain : gitco.tld cc_compile_date : Tue Jan 20 23:35:28 CET 2009 xend_config_format : 4 Xen 3.0.3: [root@node2 ~]# xm info host : node2 release : 2.6.18-128.1.6.el5xen version : #1 SMP Wed Apr 1 10:38:05 EDT 2009 machine : i686 nr_cpus : 1 nr_nodes : 1 sockets_per_node : 1 cores_per_socket : 1 threads_per_core : 1 cpu_mhz : 1503 hw_caps : 3febfbff:00000000:00000000:00000080 total_memory : 2046 free_memory : 256 node_to_cpu : node0:0 xen_major : 3 xen_minor : 1 xen_extra : .2-128.1.6.el5 xen_caps : xen-3.0-x86_32p xen_pagesize : 4096 platform_params : virt_start=0xf5800000 xen_changeset : unavailable cc_compiler : gcc version 4.1.2 20080704 (Red Hat 4.1.2-44) cc_compile_by : mockbuild cc_compile_domain : centos.org cc_compile_date : Wed Apr 1 09:11:34 EDT 2009 xend_config_format : 2 Hany On Thu, Jun 11, 2009 at 4:46 AM, Daniel P. Berrange <berrange@redhat.com>wrote:
On Wed, Jun 10, 2009 at 07:28:51PM -0400, Hany Fahim wrote:
Hey Daniel, Here is the output of 'xm list' from both machines:
I wanted the 'xm info' output actually....
Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/:| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org:| |: http://autobuild.org -o- http://search.cpan.org/~danberr/:| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Thu, Jun 11, 2009 at 02:13:17PM -0400, Hany Fahim wrote:
My apologies. Here it is: Xen 3.3:
[root@node1 ~]# xm info total_memory : 3063 free_memory : 128 node_to_cpu : node0:0-1 node_to_memory : node0:128 xen_major : 3 xen_minor : 3 xen_extra : .1
Xen 3.0.3:
[root@node2 ~]# xm info total_memory : 2046 free_memory : 256 node_to_cpu : node0:0 xen_major : 3 xen_minor : 1 xen_extra : .2-128.1.6.el5
This shows that the Hypervisor is giving correct info back with both versions. So the problem must be at the libvirt space, and I believe I know what the problem is. The version of Xen in RHEL5 has struct xen_sysctl_availheap { /* IN variables. */ uint32_t min_bitwidth; /* Smallest address width (zero if don't care). */ uint32_t max_bitwidth; /* Largest address width (zero if don't care). */ int32_t node; /* NUMA node of interest (-1 for all nodes). */ /* OUT variables. */ uint64_t avail_bytes; /* Bytes available in the specified region. */ }; While upstream Xen has struct xen_sysctl_availheap { /* IN variables. */ uint32_t min_bitwidth; /* Smallest address width (zero if don't care). */ uint32_t max_bitwidth; /* Largest address width (zero if don't care). */ int32_t node; /* NUMA node of interest (-1 for all nodes). */ /* OUT variables. */ uint64_aligned_t avail_bytes;/* Bytes available in the specified region. */ }; Notice the 'avail_bytes' field is now aligned, so its 4 bytes further down from where libvirt is expecting it to be. We'll have to provide a fix in libvirt to use the new alignment for newer Xen. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Thanks Daniel, Is it fair to assume this fix may appear in the next release of libvirt? Hany On Thu, Jun 11, 2009 at 2:28 PM, Daniel P. Berrange <berrange@redhat.com>wrote:
On Thu, Jun 11, 2009 at 02:13:17PM -0400, Hany Fahim wrote:
My apologies. Here it is: Xen 3.3:
[root@node1 ~]# xm info total_memory : 3063 free_memory : 128 node_to_cpu : node0:0-1 node_to_memory : node0:128 xen_major : 3 xen_minor : 3 xen_extra : .1
Xen 3.0.3:
[root@node2 ~]# xm info total_memory : 2046 free_memory : 256 node_to_cpu : node0:0 xen_major : 3 xen_minor : 1 xen_extra : .2-128.1.6.el5
This shows that the Hypervisor is giving correct info back with both versions. So the problem must be at the libvirt space, and I believe I know what the problem is.
The version of Xen in RHEL5 has
struct xen_sysctl_availheap { /* IN variables. */ uint32_t min_bitwidth; /* Smallest address width (zero if don't care). */ uint32_t max_bitwidth; /* Largest address width (zero if don't care). */ int32_t node; /* NUMA node of interest (-1 for all nodes). */ /* OUT variables. */ uint64_t avail_bytes; /* Bytes available in the specified region. */ };
While upstream Xen has
struct xen_sysctl_availheap { /* IN variables. */ uint32_t min_bitwidth; /* Smallest address width (zero if don't care). */ uint32_t max_bitwidth; /* Largest address width (zero if don't care). */ int32_t node; /* NUMA node of interest (-1 for all nodes). */ /* OUT variables. */ uint64_aligned_t avail_bytes;/* Bytes available in the specified region. */ };
Notice the 'avail_bytes' field is now aligned, so its 4 bytes further down from where libvirt is expecting it to be.
We'll have to provide a fix in libvirt to use the new alignment for newer Xen.
Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/:| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org:| |: http://autobuild.org -o- http://search.cpan.org/~danberr/:| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Thu, Jun 11, 2009 at 02:37:57PM -0400, Hany Fahim wrote:
Thanks Daniel, Is it fair to assume this fix may appear in the next release of libvirt?
If you want to build from source, I'd appreciate feedback on whether the following patch fixes the problem diff -r f204769dd197 src/xen_internal.c --- a/src/xen_internal.c Wed Jun 03 13:52:06 2009 +0000 +++ b/src/xen_internal.c Fri Jun 12 15:44:05 2009 +0100 @@ -241,6 +241,15 @@ struct xen_v2s4_availheap { typedef struct xen_v2s4_availheap xen_v2s4_availheap; +struct xen_v2s5_availheap { + uint32_t min_bitwidth; /* Smallest address width (zero if don't care). */ + uint32_t max_bitwidth; /* Largest address width (zero if don't care). */ + int32_t node; /* NUMA node (-1 for sum across all nodes). */ + uint64_t avail_bytes ALIGN_64; /* Bytes available in the specified region. */ +}; + +typedef struct xen_v2s5_availheap xen_v2s5_availheap; + #define XEN_GETDOMAININFOLIST_ALLOC(domlist, size) \ (hypervisor_version < 2 ? \ @@ -650,6 +659,7 @@ struct xen_op_v2_sys { xen_v2s3_getdomaininfolistop getdomaininfolists3; xen_v2_getschedulerid getschedulerid; xen_v2s4_availheap availheap; + xen_v2s5_availheap availheap5; uint8_t padding[128]; } u; }; @@ -3125,12 +3135,18 @@ xenHypervisorNodeGetCellsFreeMemory(virC op_sys.cmd = XEN_V2_OP_GETAVAILHEAP; for (i = startCell, j = 0;(i < priv->nbNodeCells) && (j < maxCells);i++,j++) { - op_sys.u.availheap.node = i; + if (sys_interface_version >= 5) + op_sys.u.availheap5.node = i; + else + op_sys.u.availheap.node = i; ret = xenHypervisorDoV2Sys(priv->handle, &op_sys); if (ret < 0) { return(-1); } - freeMems[j] = op_sys.u.availheap.avail_bytes; + if (sys_interface_version >= 5) + freeMems[j] = op_sys.u.availheap5.avail_bytes; + else + freeMems[j] = op_sys.u.availheap.avail_bytes; } return (j); }
This shows that the Hypervisor is giving correct info back with both versions. So the problem must be at the libvirt space, and I believe I know what the problem is.
The version of Xen in RHEL5 has
struct xen_sysctl_availheap { /* IN variables. */ uint32_t min_bitwidth; /* Smallest address width (zero if don't care). */ uint32_t max_bitwidth; /* Largest address width (zero if don't care). */ int32_t node; /* NUMA node of interest (-1 for all nodes). */ /* OUT variables. */ uint64_t avail_bytes; /* Bytes available in the specified region. */ };
While upstream Xen has
struct xen_sysctl_availheap { /* IN variables. */ uint32_t min_bitwidth; /* Smallest address width (zero if don't care). */ uint32_t max_bitwidth; /* Largest address width (zero if don't care). */ int32_t node; /* NUMA node of interest (-1 for all nodes). */ /* OUT variables. */ uint64_aligned_t avail_bytes;/* Bytes available in the specified region. */ };
Notice the 'avail_bytes' field is now aligned, so its 4 bytes further down from where libvirt is expecting it to be.
We'll have to provide a fix in libvirt to use the new alignment for newer Xen.
Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Hey Daniel, I just patched the source and compiled. It properly reports the free memory now: [root@node1 ~]# python Python 2.4.3 (#1, Jan 21 2009, 01:10:13) [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import libvirt conn = libvirt.open('xen:///') print(conn.getFreeMemory()) 134217728
Thanks for all your help! Hany On Fri, Jun 12, 2009 at 10:44 AM, Daniel P. Berrange <berrange@redhat.com>wrote:
On Thu, Jun 11, 2009 at 02:37:57PM -0400, Hany Fahim wrote:
Thanks Daniel, Is it fair to assume this fix may appear in the next release of libvirt?
If you want to build from source, I'd appreciate feedback on whether the following patch fixes the problem
diff -r f204769dd197 src/xen_internal.c --- a/src/xen_internal.c Wed Jun 03 13:52:06 2009 +0000 +++ b/src/xen_internal.c Fri Jun 12 15:44:05 2009 +0100 @@ -241,6 +241,15 @@ struct xen_v2s4_availheap {
typedef struct xen_v2s4_availheap xen_v2s4_availheap;
+struct xen_v2s5_availheap { + uint32_t min_bitwidth; /* Smallest address width (zero if don't care). */ + uint32_t max_bitwidth; /* Largest address width (zero if don't care). */ + int32_t node; /* NUMA node (-1 for sum across all nodes). */ + uint64_t avail_bytes ALIGN_64; /* Bytes available in the specified region. */ +}; + +typedef struct xen_v2s5_availheap xen_v2s5_availheap; +
#define XEN_GETDOMAININFOLIST_ALLOC(domlist, size) \ (hypervisor_version < 2 ? \ @@ -650,6 +659,7 @@ struct xen_op_v2_sys { xen_v2s3_getdomaininfolistop getdomaininfolists3; xen_v2_getschedulerid getschedulerid; xen_v2s4_availheap availheap; + xen_v2s5_availheap availheap5; uint8_t padding[128]; } u; }; @@ -3125,12 +3135,18 @@ xenHypervisorNodeGetCellsFreeMemory(virC op_sys.cmd = XEN_V2_OP_GETAVAILHEAP;
for (i = startCell, j = 0;(i < priv->nbNodeCells) && (j < maxCells);i++,j++) { - op_sys.u.availheap.node = i; + if (sys_interface_version >= 5) + op_sys.u.availheap5.node = i; + else + op_sys.u.availheap.node = i; ret = xenHypervisorDoV2Sys(priv->handle, &op_sys); if (ret < 0) { return(-1); } - freeMems[j] = op_sys.u.availheap.avail_bytes; + if (sys_interface_version >= 5) + freeMems[j] = op_sys.u.availheap5.avail_bytes; + else + freeMems[j] = op_sys.u.availheap.avail_bytes; } return (j); }
This shows that the Hypervisor is giving correct info back with both versions. So the problem must be at the libvirt space, and I believe I know what the problem is.
The version of Xen in RHEL5 has
struct xen_sysctl_availheap { /* IN variables. */ uint32_t min_bitwidth; /* Smallest address width (zero if don't
care).
*/ uint32_t max_bitwidth; /* Largest address width (zero if don't care). */ int32_t node; /* NUMA node of interest (-1 for all nodes). */ /* OUT variables. */ uint64_t avail_bytes; /* Bytes available in the specified region. */ };
While upstream Xen has
struct xen_sysctl_availheap { /* IN variables. */ uint32_t min_bitwidth; /* Smallest address width (zero if don't care). */ uint32_t max_bitwidth; /* Largest address width (zero if don't care). */ int32_t node; /* NUMA node of interest (-1 for all nodes). */ /* OUT variables. */ uint64_aligned_t avail_bytes;/* Bytes available in the specified region. */ };
Notice the 'avail_bytes' field is now aligned, so its 4 bytes further down from where libvirt is expecting it to be.
We'll have to provide a fix in libvirt to use the new alignment for newer Xen.
Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/:| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org:| |: http://autobuild.org -o- http://search.cpan.org/~danberr/:| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Fri, Jun 12, 2009 at 03:44:50PM +0100, Daniel P. Berrange wrote:
On Thu, Jun 11, 2009 at 02:37:57PM -0400, Hany Fahim wrote:
Thanks Daniel, Is it fair to assume this fix may appear in the next release of libvirt?
If you want to build from source, I'd appreciate feedback on whether the following patch fixes the problem
diff -r f204769dd197 src/xen_internal.c --- a/src/xen_internal.c Wed Jun 03 13:52:06 2009 +0000 +++ b/src/xen_internal.c Fri Jun 12 15:44:05 2009 +0100 @@ -241,6 +241,15 @@ struct xen_v2s4_availheap {
typedef struct xen_v2s4_availheap xen_v2s4_availheap;
+struct xen_v2s5_availheap { + uint32_t min_bitwidth; /* Smallest address width (zero if don't care). */ + uint32_t max_bitwidth; /* Largest address width (zero if don't care). */ + int32_t node; /* NUMA node (-1 for sum across all nodes). */ + uint64_t avail_bytes ALIGN_64; /* Bytes available in the specified region. */ +}; + +typedef struct xen_v2s5_availheap xen_v2s5_availheap; +
#define XEN_GETDOMAININFOLIST_ALLOC(domlist, size) \ (hypervisor_version < 2 ? \ @@ -650,6 +659,7 @@ struct xen_op_v2_sys { xen_v2s3_getdomaininfolistop getdomaininfolists3; xen_v2_getschedulerid getschedulerid; xen_v2s4_availheap availheap; + xen_v2s5_availheap availheap5; uint8_t padding[128]; } u; }; @@ -3125,12 +3135,18 @@ xenHypervisorNodeGetCellsFreeMemory(virC op_sys.cmd = XEN_V2_OP_GETAVAILHEAP;
for (i = startCell, j = 0;(i < priv->nbNodeCells) && (j < maxCells);i++,j++) { - op_sys.u.availheap.node = i; + if (sys_interface_version >= 5) + op_sys.u.availheap5.node = i; + else + op_sys.u.availheap.node = i; ret = xenHypervisorDoV2Sys(priv->handle, &op_sys); if (ret < 0) { return(-1); } - freeMems[j] = op_sys.u.availheap.avail_bytes; + if (sys_interface_version >= 5) + freeMems[j] = op_sys.u.availheap5.avail_bytes; + else + freeMems[j] = op_sys.u.availheap.avail_bytes; } return (j); }
Looks fine to me, ACK. Just one small worry, did we precisely identify when the change happened ? In xenHypervisorInit we go directly from sys_interface_version of 4 to 6, we never try 5 as far as I can see. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Mon, Jun 15, 2009 at 12:09:13PM +0200, Daniel Veillard wrote:
On Fri, Jun 12, 2009 at 03:44:50PM +0100, Daniel P. Berrange wrote:
On Thu, Jun 11, 2009 at 02:37:57PM -0400, Hany Fahim wrote:
Thanks Daniel, Is it fair to assume this fix may appear in the next release of libvirt?
If you want to build from source, I'd appreciate feedback on whether the following patch fixes the problem
diff -r f204769dd197 src/xen_internal.c --- a/src/xen_internal.c Wed Jun 03 13:52:06 2009 +0000 +++ b/src/xen_internal.c Fri Jun 12 15:44:05 2009 +0100 @@ -241,6 +241,15 @@ struct xen_v2s4_availheap {
typedef struct xen_v2s4_availheap xen_v2s4_availheap;
+struct xen_v2s5_availheap { + uint32_t min_bitwidth; /* Smallest address width (zero if don't care). */ + uint32_t max_bitwidth; /* Largest address width (zero if don't care). */ + int32_t node; /* NUMA node (-1 for sum across all nodes). */ + uint64_t avail_bytes ALIGN_64; /* Bytes available in the specified region. */ +}; + +typedef struct xen_v2s5_availheap xen_v2s5_availheap; +
#define XEN_GETDOMAININFOLIST_ALLOC(domlist, size) \ (hypervisor_version < 2 ? \ @@ -650,6 +659,7 @@ struct xen_op_v2_sys { xen_v2s3_getdomaininfolistop getdomaininfolists3; xen_v2_getschedulerid getschedulerid; xen_v2s4_availheap availheap; + xen_v2s5_availheap availheap5; uint8_t padding[128]; } u; }; @@ -3125,12 +3135,18 @@ xenHypervisorNodeGetCellsFreeMemory(virC op_sys.cmd = XEN_V2_OP_GETAVAILHEAP;
for (i = startCell, j = 0;(i < priv->nbNodeCells) && (j < maxCells);i++,j++) { - op_sys.u.availheap.node = i; + if (sys_interface_version >= 5) + op_sys.u.availheap5.node = i; + else + op_sys.u.availheap.node = i; ret = xenHypervisorDoV2Sys(priv->handle, &op_sys); if (ret < 0) { return(-1); } - freeMems[j] = op_sys.u.availheap.avail_bytes; + if (sys_interface_version >= 5) + freeMems[j] = op_sys.u.availheap5.avail_bytes; + else + freeMems[j] = op_sys.u.availheap.avail_bytes; } return (j); }
Looks fine to me, ACK. Just one small worry, did we precisely identify when the change happened ? In xenHypervisorInit we go directly from sys_interface_version of 4 to 6, we never try 5 as far as I can see.
That's not a problem, because version 5 only ever appeared in the xen-unstable.hg tree for a month or two. 3.1.0 was version 4, and 3.2.0 went to version 6. So there's no compelling reason to check for version 5 really. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Hany Fahim