https://bugzilla.redhat.com/show_bug.cgi?id=1426162
Turns out, some aarch64 systems have SMBIOS info. That means we
can use dmidecode to fetch some information. If that fails, fall
back to the old behaviour.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
There's nothing x86 specific about this function. Rename the
function so that it has DMI suffix which enables it to be reused
on different arches (as using X86 from say ARM would look
suspicious).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Due to the way that our virObjectUnref() is written it's not
possible that a NULL is passed into *Dispose() function. However,
some functions check for that regardless.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
If an FD is passed into a child using:
virCommandPassFD(cmd, fd, VIR_COMMAND_PASS_FD_CLOSE_PARENT);
then the parent should refrain from touching @fd thereafter. This
is even documented in virCommandPassFD() comment. The reason is
that either at virCommandRun()/virCommandRunAsync() or
virCommandFree() time the @fd will be closed. Closing it earlier,
e.g. right after virCommandPassFD() call might result in
undesired results. Another thread might open a file and receive
the same FD which is then unexpectedly closed by virCommandFree()
or virCommandRun().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1710575
It may happen that the system where libvirt is built at doesn't
have udevadm binary but the one where it runs does have it.
If we change how udevadm is run in virWaitForDevices() then we
can safely pass a default value in m4 macro.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The udevsettle binary is no longer used anywhere as it was
replaced by 'udevadm settle'. There's no reason for us to even
check for it in configure.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It's not true that there is a backup loop. There isn't. Drop this
part of the comment to not confuse anybody.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The idea of virCommand* APIs is that a possible error that
occurred while constructing cmd line is kept in virCommand
struct. If that's the case all subsequent calls to virCommand*()
are NO-OPs or they return an error. Well,
virCommandPassFDGetFDIndex() is not honoring that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The qsort element is a pointer of virResctrlMonitorStats, and
the comparing function's arguments have a type of pointer of
virResctrlMonitorStatsPtr.
Signed-off-by: Huaqiang <huaqiang.wang@intel.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
If no board was detected then VIR_REALLOC_N() done at the end of
the function will actually free the memory (because nborads ==
0), but @boards will be set to a non-NULL pointer. This makes it
unnecessary harder for a caller to see if any board was detected.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Currently, the way virBufferFreeAndReset() works is it relies on
virBufferContentAndReset() to fetch the buffer content which is
then freed. This works as long as there is no bug in virBuffer*
implementation (not true apparently). Explicitly call free() over
buffer content.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The @error member can contain a positive value (errno) or a
negative value (-1) to denote a usage error. It doesn't make
much sense to store it as unsigned then.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
If an error occurs in a virBuffer* API the idea is to free the
content immediately and set @error member used in error reporting
later. Well, this is not what how virBufferAddBuffer works.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This commit is similar with 692400f4. It fixes an uninitialized
variable to avoid garbage value. This case, returns 0 jiffies if an
error occurs with virNetDevBridgeGet.
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
In cases when the hash function for a name collides with other entry
already in the hash we prepend to the bucket. This creates a 'stack
effect' on the buckets if we then iterate through the hash. Normally
this is not a problem, but in tests we want deterministic results.
Since it does not matter where we add the entry and it's usually more
probable that a different entry will be accessed next change it to
append to the end of the bucket. Luckily we already iterate throught the
bucket once thus we can easily find the last entry and just connect the
new entry after it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
virCgroup struct is always defined and the free function is not calling
anything that would require OS supporting cgroups.
This fixes an issue if we try to start a VM with QEMU binary that
doesn't support QXL. The start operation will fail in
qemuProcessStartValidateVideo() which will set correct error message,
but later in one of the cleanup paths we will call
qemuDomainObjPrivateDataClear() which always calls virCgroupFree()
and that will fail on OS that doesn't support cgroups and it will
set a new error which will be eventually reported to user.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
If a bitmap of a shorter length than the data buffer is passed to
virBitmapToDataBuf, it will read off the end of the bitmap and copy junk
into the returned buffer. Add a check to only copy the length of the
bitmap to the buffer.
The problem can be observed after setting a vcpu affinity using the vcpupin
command on a system with a large number of cores:
# virsh vcpupin example_domain 0 0
# virsh vcpupin example_domain 0
VCPU CPU Affinity
---------------------------
0 0,192,197-198,202
Signed-off-by: John Allen <john.allen@amd.com>
hostdevs have a link back to the original network device. This is fairly
generic accepting any type of device, however, we don't intend to make
use of this approach in future. It can thus be specialized to network
devices.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When virDBusMessageRead() and virDBusMessageDecode were first added in
commit 834c9c94, they were identical except that virDBusMessageRead()
would unref the message after decoding it.
This difference was eliminated later in commit dc7f3ffc after it
became apparent that unref-ing the message so soon was never the right
thing to do. The two identical functions remained though, with the
tests and virDBus library itself calling the Decode variant, and all
other users calling the Read variant.
This patch eliminates the duplication, switching all users to
virDBusMessageDecode (and moving the nice API documentation comment
from the Read function up to the Decode function).
Signed-off-by: Laine Stump <laine@laine.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Spotted by Lintian (manpage-has-bad-whatis-entry tag).
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Model specific registers are a thing only on x86. Also, the
/dev/cpu/0/msr path exists only on Linux and the fallback
mechanism (asking KVM) exists on Linux and FreeBSD only.
Therefore, move the function within #ifdef that checks all
aforementioned constraints and provide a dummy stub for all
other cases.
This fixes the build on my arm box, mingw-* builds, etc.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The new virHostCPUGetMSR internal API will try to read the MSR from
/dev/cpu/0/msr and if it is not possible (the device does not exist or
libvirt is running unprivileged), it will fallback to asking KVM for the
MSR using KVM_GET_MSRS ioctl.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Vim has trouble figuring out the filetype automatically because
the name doesn't follow existing conventions; annotations like
the ones we already have in Makefile.ci help it out.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Firstly, virCommandRun() does report an error on failure (which
in most cases is more accurate than what we overwrite it with).
Secondly, usually errno is not set (or gets overwritten in the
cleanup code) which makes virReportSystemError() report useless
error messages. Drop all virReportSystemError() calls in cases
like this (I've found three occurrences).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The 'bandwidths' variable is allocated using VIR_RESIZE_N so it has to
be freed as well.
==118315== 8 bytes in 1 blocks are definitely lost in loss record 299 of 2,401
==118315== at 0x4C29DAD: malloc (vg_replace_malloc.c:308)
==118315== by 0x4C2C100: realloc (vg_replace_malloc.c:836)
==118315== by 0x52C3FAF: virReallocN (viralloc.c:245)
==118315== by 0x52C4079: virExpandN (viralloc.c:294)
==118315== by 0x532BBA8: virResctrlAllocParseProcessMemoryBandwidth (virresctrl.c:1156)
==118315== by 0x532BBA8: virResctrlAllocParseMemoryBandwidthLine (virresctrl.c:1211)
==118315== by 0x532BBA8: virResctrlAllocParse (virresctrl.c:1414)
==118315== by 0x532BBA8: virResctrlAllocGetGroup (virresctrl.c:1446)
==118315== by 0x532C11D: virResctrlAllocGetDefault (virresctrl.c:1464)
==118315== by 0x532D15E: virResctrlAllocAssign (virresctrl.c:1923)
==118315== by 0x532D15E: virResctrlAllocCreate (virresctrl.c:2042)
==118315== by 0x31E1ABEE: qemuProcessResctrlCreate (qemu_process.c:2596)
==118315== by 0x31E1ABEE: qemuProcessLaunch (qemu_process.c:6444)
==118315== by 0x31E1E341: qemuProcessStart (qemu_process.c:6721)
==118315== by 0x31E81315: qemuDomainObjStart.constprop.50 (qemu_driver.c:7288)
==118315== by 0x31E81A65: qemuDomainCreateWithFlags (qemu_driver.c:7341)
==118315== by 0x54DDB4B: virDomainCreate (libvirt-domain.c:6534)
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Standardize on putting the _LAST enum value on the second line
of VIR_ENUM_IMPL invocations. Later patches that add string labels
to VIR_ENUM_IMPL will push most of these to the second line anyways,
so this saves some noise.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The function open-codes addition into an array. Use the helper instead.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This reverts commit a5e1602090.
Getting rid of unistd.h from our headers will require more work than
just fixing the broken mingw build. Revert it until I have a more
complete proposal.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
util/virutil.h bogously included unistd.h. Drop it and replace it by
including it directly where needed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virutil.(c|h) is a very gross collection of random code. Remove the enum
handlers from there so we can limit the scope where virtutil.h is used.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'viralloc.h' does not provide any type or macro which would be necessary
in headers. Prevent leakage of the inclusion.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Keeping them with viralloc.h forcibly pulls in the other stuff from
viralloc.h into other header files. This in turn creates a mess
as more and more headers pull in the 'viral' header file.
If we want to make 'viralloc.h' omnipresent we should pick a different
approach.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This commit fixes an unitialized variable to avoid garbage value
when virNetDevBridgeGet method returns error. When, that method fails
before initialize 'val' variable, it can cause problems related to
that.
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This helper has solely to do with virObjects. Move it together with
other virObject stuff.
This also avoids the potential problem where VIR_AUTOUNREF uses
virObjectAutoUnref which is defined in virobject.h.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This helper returns the default hugetlbfs mount point from given
array of mount points.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since commit 66460e3 dropped support for YAJL 1, we no longer need
these.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Now that we do not need to cater to YAJL 1, move the check for the
return value of yajl_gen_alloc earlier, so that we can assume it
was successful in later code.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Now that we require YAJL2, drop the code dealing with YAJL 1.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We have tests that validate the XML formatter. Additionally almost every
guide tells users to disable JSON logging. Drop logging of output string
in virJSONValueToString.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
The last step of the conversion involves copying of the generated JSON
into a separate string. We can use a virBuffer to do this as this will
also allow to subsequently use the buffer when we actually need to do
some other formatting of the string.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
Use size_t for all sizes. The '*' modifier unfortunately does require an
int so a temporary variable is necessary in the tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
