On Mon, May 11, 2015 at 09:30:06PM +0100, Richard W.M. Jones wrote: >On the s/390x architecture, libvirt may already return 0 in the >node_info->mhz field (see src/nodeinfo.c:linuxNodeInfoCPUPopulate). > >We may also want to return this on aarch64 in future, because >calculating the proper value requires SMBIOS, which is not available >on non-server-class systems (specifically on systems which don't >adhere to the SBSA standard). > >Therefore this change documents the existing behaviour and provides a >valid path for aarch64. > >Signed-off-by: Richard W.M. Jones <rjones(a)redhat.com&gt; >Bug-URL: https://bugzilla.redhat.com/1206353 >--- >include/libvirt/libvirt-host.h | 3 ++- >1 file changed, 2 insertions(+), 1 deletion(-) > >diff --git a/include/libvirt/libvirt-host.h b/include/libvirt/libvirt-host.h >index 953366b..070550b 100644 >--- a/include/libvirt/libvirt-host.h >+++ b/include/libvirt/libvirt-host.h >@@ -354,7 +354,8 @@ struct _virNodeInfo { > char model[32]; /* string indicating the CPU model */ > unsigned long memory; /* memory size in kilobytes */ > unsigned int cpus; /* the number of active CPUs */ >- unsigned int mhz; /* expected CPU frequency */ >+ unsigned int mhz; /* expected CPU frequency, 0 if not known or >+ on unusual architectures */ I feel like if this is documented (which is fine), then clients (virsh in particular) should be modified to work with such behaviour (e.g. not print that info).

> unsigned int nodes; /* the number of NUMA cell, 1 for unusual NUMA > topologies or uniform memory access; check > capabilities XML for the actual NUMA topology */ >-- >2.3.1 > >-- >libvir-list mailing list &gt;libvir-list(a)redhat.com >https://www.redhat.com/mailman/listinfo/libvir-list

-- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list