We prefer c89 style of comments.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

And use it in virFileRead*
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Previously, this function must've been called only on Linux in order
to fail gracefully.  That lead to #ifdef mess in callers, so the
function was redesigned so it failed gracefully on non-existing
files.  However that commit forgot to define the function outside the
__linux__ ifdef, it broke non-Linux builds.

Caused by c67e04e2.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

While on that, drop support for kernels from RHEL-5 era (missing
cpu/present file).  Also add some useful functions and export them.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

The functions to retrieve online and present host CPU information
are only supported on Linux for the time being.

This leads to runtime errors if these function are used on other
platforms. To avoid that, code in higher levels using the functions
must replicate the conditional compilation in higher level which
is error prone (and is plainly spoken ugly).

Adding a function virHostCPUHasBitmap that can be used to check
for host CPU bitmap support.

NB: There are other functions including the host CPU count that
are lacking support on all platforms, but they are too essential
in order to be bypassed.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

There is nothing Linux-specific in that function.  Also since commit
8c3b5bf4 mingw build is broken due to
the fact that this function is not compiled in the library.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

We will need this function shortly when implementing
nodeGetCPUStats in the test driver.
Signed-off-by: NTomáš Ryšavý <tom.rysavy.0@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Current implementation uses the dev.cpu.0.freq sysctl that is
provided by the cpufreq(4) framework and returns the actual
CPU frequency. However, there are environments where it's not available,
e.g. when running nested in KVM. In this case fall back to hw.clockrate
that reports CPU frequency at the boot time.

Resolves (hopefully):
https://bugzilla.redhat.com/show_bug.cgi?id=1369964

All Linux releases we support (RHEL6 era) include these
definitions.

If we don't HAVE_LINUX_KVM_H, we can't query /dev/kvm to discover
the limits on the number of vCPUs, so we report an error and
return a negative value instead.

Remove the local kvmpath variable from
virHostCPUGetThreadsPerSubcore() and use the file-global
KVM_DEVICE define instead.

This kvmGetMaxVCPUs() needs to be used at two different places
so move it to utils with appropriate name and mark it as private
global now.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>

Remove all the remaining usage of opendir.

Switch from opendir to virDirOpen everywhere we need to report an error.

Introduce a helper that only calls closedir if DIR* is non-NULL
and sets it to NULL afterwards.

The only possible error is EBADFD.
Since we only use the directory stream returned by opendir,
this should never happen.

Most the callers pass 0 in one form or another, including
vircapstest which used VIR_ARCH_NONE.

This function is plenty of ifdefs providing implementations for
Linux, *BSD and OS-X. However, if we are being build for any
other architecture, all that's left behind by preprocessor is
just a error reporting call and return of -1. In that case,
passed arguments are unused:

../../src/util/virhostcpu.c: In function 'virHostCPUGetInfo':
../../src/util/virhostcpu.c:966:33: error: unused parameter 'cpus' [-Werror=unused-parameter]
                   unsigned int *cpus,
                                 ^~~~
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

 * Fix misspelt function name:
    s/virHostCPUGetStatsFreebsd/virHostCPUGetStatsFreeBSD/
 * Mark the first argument to virHostCPUGetInfo with ATTRIBUTE_UNUSED
   as it's not actually used on non-Linux

Move all APIs with a virHostCPU name prefix out into new
util/virhostcpu.h & util/virhostcpu.c files
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

In preparation for moving all the CPU related APIs out of
the nodeinfo file, give them a virHostCPU name prefix.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

In preparation for moving all the memory related APIs out of
the nodeinfo file, give them a virHostMem name prefix.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Instead of having platform specific code in nodeGetInfo to
fetch CPU topology, split it all out into a new method
nodeGetCPUInfo.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The GNULIB physmem module already provides support for
the FreeBSD platform, so there's no reason to re-implement
FreeBSD portability code in libvirt. If there are bugs in
the GNULIB code, we should fix GNULIB rather than workaround
it in libvirt.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The nodeGetInfo() method currently has its own code for getting
memory size in KB, that basically just re-invents what nodeGetMemory
already does. Remove it and just call nodeGetMemory, converting its
result from bytes to KB, allowing removal of more platform specific
conditional code.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Nearly all the methods in the nodeinfo file are given a
'const char *sysfs_prefix' parameter to override the
default sysfs path (/sys/devices/system). Every single
caller passes in NULL for this, except one use in the
unit tests. Furthermore this parameter is totally
Linux-specific, when the APIs are intended to be cross
platform portable.

This removes the sysfs_prefix parameter and instead gives
a new method linuxNodeInfoSetSysFSSystemPath for use by
the test suite.

For two of the methods this hardcodes use of the constant
SYSFS_SYSTEM_PATH, since the test suite does not need to
override the path for thos methods.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The manpage for sysconf() suggest including unistd.h as the
function is declared there. Even though we are not hitting any
compile issues currently, let's include the correct header file
instead of relying on some hidden include chain.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Compiler error:

  ../../src/nodeinfo.c: In function 'nodeGetThreadsPerSubcore':
  ../../src/nodeinfo.c:2393: error: label 'out' defined but not used [-Wunused-label]
  ../../src/nodeinfo.c:2352: error: unused parameter 'arch' [-Wunused-parameter]

The nodeinfo is reporting incorrect number of cpus and incorrect host
topology on PPC64 KVM hosts. The KVM hypervisor on PPC64 needs only
the primary thread in a core to be online, and the secondaries offlined.
While scheduling a guest in, the kvm scheduler wakes up the secondaries to
run in guest context.

The host scheduling of the guests happen at the core level(as only primary
thread is online). The kvm scheduler exploits as many threads of the core
as needed by guest. Further, starting POWER8, the processor allows splitting
a physical core into multiple subcores with 2 or 4 threads each. Again, only
the primary thread in a subcore is online in the host. The KVM-PPC
scheduler allows guests to exploit all the offline threads in the subcore,
by bringing them online when needed.
(Kernel patches on split-core http://www.spinics.net/lists/kvm-ppc/msg09121.html)

Recently with dynamic micro-threading changes in ppc-kvm, makes sure
to utilize all the offline cpus across guests, and across guests with
different cpu topologies.
(https://www.mail-archive.com/kvm@vger.kernel.org/msg115978.html)

Since the offline cpus are brought online in the guest context, it is safe
to count them as online. Nodeinfo today discounts these offline cpus from
cpu count/topology calclulation, and the nodeinfo output is not of any help
and the host appears overcommited when it is actually not.

The patch carefully counts those offline threads whose primary threads are
online. The host topology displayed by the nodeinfo is also fixed when the
host is in valid kvm state.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Move the calls to the respective functions from virNodeParseNode(),
which is executed once for every NUMA node, to
linuxNodeInfoCPUPopulate(), which is executed just once per host.

Keep track of what CPUs belong to the current node while walking
through the sysfs node entry, so we don't need to do it a second
time immediately afterwards.

This also allows us to loop through all CPUs that are part of a
node in guaranteed ascending order, which is something that is
required for some upcoming changes.

No need to look up the online status of each CPU separately when we
can get all the information in one go.

Swap out all instances of cpu_set_t and replace them with virBitmap,
which some of the code was already using anyway.

The changes are pretty mechanical, with one notable exception: an
assumption has been added on the max value we can run into while
reading either socket_it or core_id.

While this specific assumption was not in place before, we were
using cpu_set_t improperly by not making sure not to set any bit
past CPU_SETSIZE or explicitly allocating bigger bitmaps; in fact
the default size of a cpu_set_t, 1024, is way too low to run our
testsuite, which includes core_id values in the 2000s.

The new name makes it clear that the returned bitmap contains the
information about which CPUs are online, not eg. which CPUs are
present.

No behavioral change.

Not all users of this API will need the size of the returned
bitmap; those who do can simply call virBitmapSize() themselves.

If the cpu/present file is not available, we assume that the kernel
is too old to support non-consecutive CPU ids and return a bitmap
with all the bits set to represent this fact. This assumption is
already exploited in nodeGetCPUCount().

This means users of this API can expect the information to always
be available unless an error has occurred, and no longer need to
treat the NULL return value as a special case.

The error message has been updated as well.

The original name was confusing because the function returns the number
of CPUs, not the maximum CPU id. The comment above the function has
been updated to reflect this.

No behavioral changes.