Similarly to the refactor of virXPath(U)LongLong drop the ability to
convert from the internal double value forcing the use of the 'string()'
conversion.
In case of 32 bit integers there's no problem with overflows, but we can
implement the code identically to what we have in the other helpers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Passing negative number as an alias for the max value is an anti-feature
we unfortunately allowed in virsh, but luckily never encouraged in the
XML.
Refuse numbers with negative sign when parsing unsigned long long from
XPaths.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The conversion from double is not precise enough at the extremes so it
must not be used.
Spell out that the callers are required to use a string() conversion in
the XPath expression and remove the code path handling the direct
conversion from numbers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Extract the internals of virXPathString which evaluate the XPath and
validate that the returned object is a string into a new helper named
'virXPathEvalString'.
The function will be later reused in the number XPath evaluation
functions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rename 'catchRNGError' to 'virXMLValidatorRNGErrorCatch' and
'ignoreRNGError' to 'virXMLValidatorRNGErrorIgnore'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Make the file use consistent header formatting and two line spacing
between functions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function is now referenced only within util/virxml.c other callers
should not use it directly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This reverts commit e49313b54e.
This reverts commit a0f37232b9.
Revert them together to not break build.
This fix of the issue is incorrect and breaks usage of other controllers
in hybrid mode that systemd creates, specifically usage of devices and
cpuacct controllers as they are now assumed to be part of the cgroup v2
topology which is not true.
We need to find different solution to the issue.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
systemd in hybrid mode uses v1 hierarchies for controllers and v2 for
process tracking.
The LXC code uses virCgroupAddMachineProcess() to move processes into
appropriate cgroup by manipulating cgroupfs directly. (Note, despite
libvirt also supports talking to systemd directly via
org.freedesktop.machine1 API.)
If this path is taken, libvirt/lxc must convince systemd that processes
really belong to new cgroup, i.e. also the tracking v2 hierarchy must
undergo migration too.
The current check would evaluate v2 backend as unavailable with hybrid
mode (because there are no available controllers). Simplify the
condition and consider the mounted cgroup2 as sufficient to touch v2
hierarchy.
This consequently creates an issue with binding the V2 mount. In hybrid
mode the V2 filesystem may be mounted upon the V1 filesystem. By reversing
the order in which backends are mounted in virCgroupBindMount this problem
is circumvented.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/182
Signed-off-by: Eric van Blokland <mail@ericvanblokland.nl>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There are two modes of core scheduling that are handy wrt
virCommand:
1) create new trusted group when executing a virCommand
2) place freshly executed virCommand into the trusted group of
another process.
Therefore, implement these two new operations as new APIs:
virCommandSetRunAlone() and virCommandSetRunAmong(),
respectively.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Since its 5.14 release the Linux kernel allows userspace to
define trusted groups of processes/threads that can run on
sibling Hyper Threads (HT) at the same time. This is to mitigate
side channel attacks like L1TF or MDS. If there are no tasks to
fully utilize all HTs, then a HT will idle instead of running a
task from another (un-)trusted group.
On low level, this is implemented by cookies (effectively an UL
value): processes in the same trusted group share the same cookie
and cookie is unique to the group. There are four basic
operations:
1) PR_SCHED_CORE_GET -- get cookie of given PID,
2) PR_SCHED_CORE_CREATE -- create a new unique cookie for PID,
3) PR_SCHED_CORE_SHARE_TO -- push cookie of the caller onto
another PID,
4) PR_SCHED_CORE_SHARE_FROM -- pull cookie of another PID into
the caller.
Since a system where the code is built can be different to the
one where the code is ran let's provide declaration of some
values. It's not unusual for distros to ship older linux-headers
than the actual kernel.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
With the introduction of `libvirt` sub-directory to the cgroup topology
some of the cgroup configuration was moved into that sub-directory
together with the VM processes.
LXC uses virCgroupNewSelf() in the container process to detect cgroups
in order to report various data from cgroups inside the container.
We need to properly detect the new `libvirt` sub-directory here
otherwise LXC will report incorrect data.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Change strings to use g_autofree.
Signed-off-by: Maxim Kostin <ttxinee@outlook.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The source_root() method is deprecated in 0.56.0 and we're
recommended to use project_source_root() instead.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Remove the seldom used helper in favor of full virXMLParse.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert the two outstanding uses to virXMLParseFileCtxt as they always
pass a filename and remove the helper macro.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Most callers prefer using the XPath context. Convert the last user to
use virXMLParseFileCtxt and remove the helper macro.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Most callers use virXMLParseStringCtxt. Convert the last use case
and remove the helper.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The generic helper also has helper code to validate the root element and
create an XPath context. Many places in the code duplicate code for
doing these operations.
Extend the helper to provide all arguments and fix all callers.
In many cases this patch refactors the passing of the 'validate'
field into a separate variable to avoid quirky looking arguments.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Our public API docs use the hyphenated version with capital OR. Fix the
virXMLProp* helpers to use the same syntax.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We commonly use 'const char *name' instead of 'const char* name'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Sadly some devices provide invalid VPD data even with fully updated
firmware. Former hardning like 600f580d "PCI VPD: Skip fields with
invalid values" have already helped for those to some extent.
But if one happens to have such a device installed in the system,
despite all other things working properly the log potentially
flooded with messages like:
internal error: The keyword is not comprised only of uppercase ASCII
letters or digits
internal error: A field data length violates the resource length boundary.
The user can't do anything about it to change that, they will be there on
any libvirt restart and potentially distract from other more important
issues.
Since the vpd decoding is implemented rather resilient (if parsing fails
all goes on fine, the respective device just has no VPD data populated
eventually) we can lower those from virReportError(VIR_ERR_INTERNAL_ERROR
to just VIR_INFO. If needed for debugging people can set the level
accordingly, but otherwise we would no more fill the logs with errors
without a strong reason.
Fixes: https://launchpad.net/bugs/1990949
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
VIR_XPATH_NODE_AUTORESTORE_NAME is a more generic version of the
VIR_XPATH_NODE_AUTORESTORE macro used to save the 'node' inside a XPath
context struct. The new macro allows specifying the name of the variable
used to save the context so that it can be used multiple times inside a
function's nested scopes.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a helper for parsing long long values from XML properties with
semantics like virXMLPropInt.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly to virXMLPropString it extracts a string but reports an error
similar to the newer virXMLProp helpers if the attribute is not present.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All callers treat NULL as if the string is not present in the XML.
Adjust the description so that it's implied that it's not an error and
thus also no error reporting is expected.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The helper function extracts a UUID with semantics similar to other
helpers we have.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
At time of writing DEVLINK_ATTR_MAX equals to 176, thus the stack'd size
of the pointer array is almost 1.4kiB. Allocate it dynamically.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use approach similar to virFileIsSharedFsFUSE to declaratively handle
the filesystem magic numbers mapping to libvirt's fstypes.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The filesystem type magic constant was added for the 'quobyte' shared
filesystem in commit 451094bd15 but is present neither in the kernel
sources nor in coreutils which we've historically used as source of
information.
Since the code dealing with FUSE-based filesystems doesn't need the
constant we can remove it and the now-dead check for it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While the code works properly as no code path is specifically wanting to
check for glusterfs, we should properly declare glusterfs as a separate
from GFS2.
Fixes: 478da65fb4
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'virFileIsSharedFixFUSE' was used to update the 'f_type' field for
certain shared filesystem types.
This patch renames it to 'virFileIsSharedFsFUSE' and makes it directly
return whether the FUSE filesystem is shared or not and simplifies
additions to the list of shared FUSE filesystems.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Automatically free memory of 'canonPath' so that the failure of
'setmntent' doesn't have to go to 'cleanup'. This allows us to remove
the cleanup section and the 'ret' variable as the rest of the function
can't fail.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Expand some of the uncommon or unobvious filesystem names in a comment.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We populate the bits individually so unsigned is the proper type.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virProcessGetStatInfo() helper parses /proc stat file for
given PID and/or TID and reports cumulative cpuTime which is just
a sum of user and sys times. But in near future, we'll need those
times separately, so make the function return them too (if caller
desires).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The most recent environment e.g. present in our Fedora Rawhide builds
fail to build the tree with clang with the following error:
../src/util/virhostcpu.c:1291:25: error: field 'header' with variable sized type 'struct kvm_msrs' not at the end of a struct or class is a GNU extension [-Werror,-Wgnu-variable-sized-type-not-at-end]
struct kvm_msrs header;
^
The problem seems to be that clang doesn't like the new way the
'entries' field in struct kvm_msrs is declared.
To work around the issue we can simply allocate the variable dynamically
and use the 'entries' member as it was intended to to access the
members.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Instead of separately building the commandline into a string to log,
just wait a few lines until we've built the virCommand object, and
call virCommandToString, which does the same thing.
(As a bonus, we were already calling virCommandToString to put the
commandline in a string in case of a failure when running it - from
the point of view of *that* usage, we're just moving the call to
virCommandToString *up* a few lines, i.e. we now only construct the
commandline string once.)
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Although the next commit will eliminate the one current use of
virFirewallRuleToString(), a future commit will once again have a use
for it, but in a different source file so it will need to be a global
function rather than static. Make that change now so that we don't get
a compile error from having an unused static function in the next
commit.
(The arg list is also changed to include the name of the command as a
separate argument rather than just assuming that it can be derived
from the rule's layer (which is correct for iptables, but won't be
correct for nftables)).
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This was a wrapper to call a function in virfirewalld.c that sends an
iptables passthrough rule to firewalld. It hasn't been used in a year
or two, and won't ever be used in the future since passthrough rules
are only supported for iptables, and we've determined that we
shouldn't use iptables passthrough rules.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virCommand module is specifically designed so that no caller
has to check for retval of individual virCommand*() APIs except
for virCommandRun() where the actual error is reported. Moreover,
virCommandNew*() use g_new0() to allocate memory and thus it's
not really possible for those APIs to return NULL. Which is why
they are even marked as ATTRIBUTE_NONNULL. But there are few
places where we do check the retval which is a dead code
effectively. Drop those checks.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
The DYLD_* environment variables on macOS have the same purpose
as the LD_* variables have on Linux. Since we're preserving the
latter by default, it makes sense to do the same for the former
as well.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This makes it nicer to use as since it cannot fail shortens the usage in all
callers.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Reviewed-by: Ján Tomko <jtomko@redhat.com>
It would be nice to be able to test the mediated device capabilities
without having physical hardware which supports it. The 'mtty' kernel
module presents a virtual parent device which is capable of creating
'fake' mediated devices, and as such it would be useful for testing.
However, the 'mtty' device is not part of an existing device subsystem
(e.g. PCI, etc), so libvirt ignores it and it does not get added to the
node device list. And because it does not get added to the node device
list, it cannot be used to create child mdevs using `virsh
nodedev-create`.
There is already a node device type capability
VIR_NODE_DEV_CAP_MDEV_TYPES that indicates whether a device supports
creating child mediated devices, but libvirt assumes that this is a
nested capability (in other words, it assumes that the primary
capability of a device is something like PCI). If we allow this
MDEV_TYPES capability to be a primary device capability, then we can
support virtual devices like 'mtty' as a parent for mediated devices.
See https://bugzilla.redhat.com/show_bug.cgi?id=2107031
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The non-Linux version of virHostCPUGetPhysAddrSize() is lacking
G_GNUC_UNUSED attribute to its @size argument which triggers an
error on all non-Linux builds. And while at it, make the function
actually signal error (ENOSYS) since it does not set the
argument.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
In virtpm.h there are two functions exposed for querying swtpm
and swtpm_setup capabilities: virTPMSwtpmCapsGet() and
virTPMSwtpmSetupCapsGet(), respectively. The capabilities we are
interested in are defined in two separate enums
(virTPMSwtpmFeature and virTPMSwtpmSetupFeature), but these
functions accept capability as an unsigned int rather than their
respective enum. While this makes sense for
virTPMBinaryGetCaps(), which is a module internal helper that
both exposed functions call, there's no need for the functions
themselves to accept unsigned int.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Currently, virJSONValueObjectHasKey() can return one of three
values:
-1 if passed object type is not VIR_JSON_TYPE_OBJECT,
0 if the key is not present, and finally
1 if the key is present.
But, neither of callers is interested in the -1 case. In fact,
some callers call this function treating -1 and 1 cases the same.
Therefore, make the function return just true/false and fix few
callers that explicitly checked for == 1 case.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The G_GNUC_NO_INLINE macro will eventually be marked as
deprecated [1] and we are recommended to use G_NO_INLINE instead.
Do the switch now, rather than waiting for compile time warning
to occur.
1: 15cd0f0461
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Currently, we require glib-2.56.0 at minimum (because of RHEL-8)
but we use G_GNUC_NO_INLINE which was introduced in 2.58.0. While
we provide an implementation for older versions, where the macro
does not exists, it's a bit more tricky than that. Since we
define GLIB_VERSION_MAX_ALLOWED we would get a compile time error
when trying to use something too new, except for G_GNUC_NO_INLINE
which was intentionally not marked as
GLIB_AVAILABLE_MACRO_IN_2_58. But this is about to change with
glib-2.73.2 (which contains commit [1]).
At the same time, we can't just bump glib and thus we have to
provide an alternative implementation without the version
annotation.
1: a6f8fe071e
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
These wrapper functions were used to adapt the virObjectUnref() function
signature for different callbacks. But in commit 0d184072, the
virObjectUnref() function was changed to return a void instead of a
bool, so these adapters are no longer necessary.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
These new capabilities will be used only to track whether
swtpm_setup is capable of TPM-1.2 and/or TPM-2.0.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This is a partial revert of 87a43a907f
The change to use g_clear_pointer() in more places was accidentally
applied to cases involving vir_g_source_unref().
In some cases, the ordering of g_source_destroy() and
vir_g_source_unref() was reversed, which resulted in the source being
marked as destroyed, after it is already unreferenced. This
use-after-free case might work in many cases, but with versions of
glib older than 2.64.0 it may defer unref to run within the main
thread to avoid a race condition, which creates a large distance
between the g_source_unref() and g_source_destroy().
In some cases, the call to vir_g_source_unref() was replaced with a
second call to g_source_destroy(), leading to a memory leak or worse.
In our experience, the symptoms were that use of libvirt-python became
slower over time, with OpenStack nova-compute initially taking around
one second to periodically query the host PCI devices, and within an
hour it was taking over a minute to complete the same operation, until
it is was eventually running this query back-to-back, resulting in the
nova-compute process consuming 100% of one CPU thread, losing its
RabbitMQ connection frequently, and showing up as down to the control
plane.
Signed-off-by: Mark Mielke <mark.mielke@gmail.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
For some types of SRIOV interfaces we create a temporary file
where the state of the interface is saved before we start
modifying it. The file is used then to restore the original
configuration when the interface is no longer associated with any
guest. For writing the file virFileWriteStr() is used. However,
it's given wrong argument: the last argument is supposed to be
mode to create the file with but virNetDevSaveNetConfig() passes
open(2) flags (O_CREAT|O_TRUNC|O_WRONLY). We need the file to be
writable and readable by root only (0600). Therefore, pass that
mode instead of gibberish.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Commit v7.1.0-136-g6a6d6bb520 refactored virProcessSetMaxMemLock by
moving its part into a new virProcessSetLimit, but lost "return -1" on
error.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
For easier attribute parsing we have virXMLProp*() family of
functions. These accept flags through which a caller can pose
some conditions onto the attribute value, for instance:
VIR_XML_PROP_NONZERO when the attribute may not be zero, etc.
What we are missing is VIR_XML_PROP_NONNEGATIVE when the
attribute value may be non-negative. Obviously, this flag makes
sense only for some members of the virXMLProp*() family.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Similarly to the 'k' modifier for integers introduce 'K' for long
integers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
We've emulated the function in virHashSteal, with a note pointing to use
the proper version. Move the code to glibcomapt.c and make it such that
builds using newer glib already use the new function.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Detected by gcc 11 -Wformat-overflow:
../../src/util/vircgroupv1.c: In function ‘virCgroupV1ValidatePlacement’:
../../src/util/virerror.h:176:5: warning: ‘%s’ directive argument is null [-Wformat-overflow=]
176 | virReportErrorHelper(VIR_FROM_THIS, code, __FILE__, \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
177 | __FUNCTION__, __LINE__, __VA_ARGS__)
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../src/util/vircgroupv1.c:411:13: note: in expansion of macro ‘virReportError’
411 | virReportError(VIR_ERR_INTERNAL_ERROR,
| ^~~~~~~~~~~~~~
../../src/util/vircgroupv1.c:412:80: note: format string is defined here
412 | _("Could not find placement for v1 controller %s at %s"),
| ^~
Signed-off-by: Scott Davis <scott.davis@starlab.io>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We have our own implementation of setns() which was introduced in
v1.2.9-rc1~190 and extended afterwards. The reason was that back
in 2014 we were dealing with glibc that in some of its older
versions did not provide the function. Mostly for non-intel
arches. Nevertheless, glibc now offers the function for all
architectures we care about (aarch64 being the freshest
architecture where the function was introduced, in glibc-2.17).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The website no longer exists and the PDF file can't even be
retrieved via archive.org.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add a method to parse a ccw device address from a string.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add virCCWDeviceAddressParseFromString and use it in nodedev udev.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Refactor virDomainDeviceCCWAddressEqual into virccw and rename method as
virCCWDeviceAddressEqual.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Refactor virDomainDeviceCCWAddressIsValid into virccw and rename method
as virCCWDeviceAddressIsValid.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Refactor virDomainCCWAddressIncrement into virccw and rename method as
virCCWDeviceAddressIncrement.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Move virDomainCCWAddressAsString into virccw and rename method as
virCCWDeviceAddressAsString.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Refactor ccw data structure virDomainDeviceCCWAddress into util virccw.h
and rename it as virCCWDeviceAddress.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If the port allocator bitmap does not have enough bits to keep the state
of the port we're going to release, the port is not reserved and thus is
trivially released without doing anything. No need to report an error in
such case.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Refactor the code to use virTypedParamList which simplifies cleanup.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The helper constructs a virTypedParamList from loose params.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The returned value is used to unlock the object, so all callers must
necessarily make use of the returned value.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The last use of this function was removed in commit 6d161bcc, so the
function is no longer used except as an internal implementation for
virCommandPassFD().
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
commit f9236200 removed the last use of this function, so it can be
dropped.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
where it can be reused by other helpers.
No changes other than the move.
Note that this makes iohelper now dependent on -lutil and -lacl.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Claudio Fontana <cfontana@suse.de>
this is in preparation for a minor refactoring of the copy
function itself out of runIO().
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In the past, we did set VLAN tag on <interface type='direct'/>.
However, during rewrite (v8.1.0-rc1~191) virNetDevSetVfConfig()
was changed and a condition that was responsible for calling
a function that sets VLAN tag was changed accidentally resulting
in VLAN tag not being set anymore.
However, because of other changes in the same patchset, it may
happen that @adminMac is NULL (this is to work around yet another
broken SRIOV driver), and thus we must refrain from setting MAC
and have to set VLAN tag only.
Fixes: 73961771a1
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2075383
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If virNetDevSetVfMac() is called with either @macaddr or
@allowRetry arguments NULL an error is reported, because this is
considered invalid use. However, the error message is not
informative as it could be.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Either create or append to existing docstring, the version (git tag)
that a given function was introduced in the format:
Since: v1.2.3
Signed-off-by: Victor Toso <victortoso@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
AMD cpus report Core (compute unit) identifiers of the cpu running the
instruction under leaf 0x8000001e. This data is not needed for libvirt
and actually breaks caching of the qemu capabilities where we check that
all of the CPU flags to be identical.
Mask out all of leaf 0x8000001e.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Raise the lower bound to '64' as that seems to currently be the first
size that can fit the CPU data for a modern cpu.
Lower the upper bound to an arbitrary 65536. So many cpu features ougth
to be enough for everyone.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In case when the 'KVM_GET_SUPPORTED_CPUID' ioctl on /dev/kvm would
fail for other reason than the documented E2BIG, our code would continue
looping and calling it while always increasing the memory buffer even
when that will not help.
Rewrite the function to allow another iteration only with the correct
errno.
Additionally rename the 'i' variable to 'alloc_size' as it's not a pure
iterator.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Move the filtering code into virHostCPUGetCPUIDFilterVolatile.
This also removes a safe but very questionable reuse of 'i' iterator in
the both the top level and nested loop. It's safe for now as the to
level loop will not iterate any more in the current state.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The commit adding the code fetching host CPU flags via the
KVM_GET_SUPPORTED_CPUID didn't describe at all why such an alghorithm is
needed.
Add a comment from the documentation outlining how the userspace
function is expected to allocate memory here.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Similarly to previous commits but with the targeting libvirt-common
in a batch.
Either create or append to existing docstring, the version (git tag)
that a given typedef, enum value, macro or function was introduced
in the format:
Since: v1.2.3
Signed-off-by: Victor Toso <victortoso@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Commit d73852c499 moved the original QEMU-specific helpers to
the utils module, which resulted in build failures on non-Unix
platforms due to the unconditional use of Unix-only symbols such
as _SC_CLK_TCK.
To deal with that situation, commit d7c64453aa made the helpers
Linux-only and added stubs for other platforms that, when called,
would always fail with ENOSYS.
However the original helpers had been carefully written so that,
while they would only be able to produce useful output on Linux,
they would still succeed on the other Unix platforms where we
build the QEMU driver.
Restore the original behavior so that calling APIs such as
virDomainGetInfo() can once again work on FreeBSD and macOS.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/298
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The new function aggregates the internal working of virXMLFormatElement
and virXMLFormatElementEmpty and also allows skipping the newline
after the opening tag to allow using this helper also in cases where we
don't format any child elements but directly a value.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We need it for a single scenario in which prop='default' has to
be treated as valid input.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Since the workaround is specific to macOS, only disable compiler
warnings when building on that platform.
While at it, update the comment to reflect the fact that the
workaround is needed for all versions of the OS, including the
modern ones that we currently target.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When changing the size of pipe that virFileWrapperFdNew() creates
we start at 1MiB and if that fails because it's above the system
wide limit we get EPERM and continue with half of the size.
However, we might get another error in which case we should
report proper system error and return failure from
virFileWrapperFdNew().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
currently the only user of virFileWrapperFdNew is the qemu driver;
virsh save is very slow with a default pipe size.
This change improves throughput by ~400% on fast nvme or ramdisk.
Best value currently measured is 1MB, which happens to be also
the kernel default for the pipe-max-size.
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
schemas are used for more than just documentation,
virsh edit fails if schemas are not available.
Therefore, fix the no-docs build by moving schemas/
to the parsing code inside src/conf/.
Signed-off-by: Claudio Fontana <cfontana@suse.de>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The virNetDevGenerateName() function uses a global array of
virNetDevGenName structs to find next unused name for network
device. This obviously needs some locking and in fact each member
of the array has its own lock. However, these members are not
virObjects, they are just plain structs, therefore
VIR_WITH_MUTEX_LOCK_GUARD() must be used instead of
VIR_WITH_OBJECT_LOCK_GUARD() to lock individual mutexes.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Commit 4e42686ade wrongly assumed how g_variant_new_parsed() works and broke
starting of domains on systems with systemd (machined).
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Since libvirt-guests script/service can operate on various URIs and we do
support both socket activation and traditional services, the ordering should be
specified for all the possible sockets and services.
Also remove the Wants= dependency since do not want to start any service. We
cannot know which one libvirt-guests is configured, so we'd have to start all
the daemons which would break if unused colliding services are not
masked (libvirtd.service in the modular case and all the modular daemon service
units in the monolithic scenario). Fortunately we can assume that the system is
configured properly to start services/sockets that are of interest to the user.
That also works with the setup described in https://libvirt.org/daemons.html .
To make it even more robust we add the daemon service into the machine units
created for individual domains as it was missing there.
https://bugzilla.redhat.com/show_bug.cgi?id=1868537
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The systemd version in RHEL-7 lacked support for the LISTEN_FDNAMES env
variable with socket activation. Since we stopped targetting RHEL-7 we
can drop some considerable amount of compatibility code.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Adding an exception for the whole file usually defeats the purpose of a
syntax check and is also likely to get forgotten once the file is
removed.
In case of the suggestion of using 'safewrite' instead of write even the
comment for safewrite states that the function needs to be used only in
certain cases.
Remove the blanket exceptions for files and use an exclude string
instead. The only instance where we keep the full file exception is for
src/libvirt-stream.c as there are multiple uses in example code in
comments where I couldn't find a nicer targetted wapproach.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Automatically free 'path' inside the loop which fills it and return the
values directly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We can exit early when the input is an empty string, and we can
avoid storing the string length in a variable since we only use
that information once.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The hw.cpufrequency sysctl, which we use to obtain the CPU
frequency on macOS, is not available when running on Apple
Silicon, and as a consequence we currently report an error
whenever such information is requested.
The virNodeInfo.mhz field, where the CPU frequency gets stored,
is documented as being zero when the information could not be
obtained, and we already do that for Linux on aarch64. Extend
this behavior to macOS on Apple Silicon.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There are few places where a virPCIDeviceAddress typed variable
is allocated on the stack but it's not initialized. This can lead
to random values of its members which in turn can lead to a
random behaviour.
Generated with help of the following spatch:
@@
identifier I;
@@
- virPCIDeviceAddress I;
+ virPCIDeviceAddress I = { 0 };
And then fixing bhyveAssignDevicePCISlots() which does declare
the variable and then explicitly zero it by calling memset() only
to set a specific member afterwards.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
When rewriting a file using virFileRewrite() and error occurs
while writing into a temporary file it's actually the callback
that can report the most accurate error. Move error reporting
into very few callback we have currently. Those callbacks are
trivial so the benefit of this change is not obvious, but this
will change shortly when slightly more complicated callback is
introduced.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Currently, due to the way virFileRewrite() works, the rewritten
file is owned by user and group that the daemon runs under. So
far, this is not a problem, because the function is used to write
XML files or secrets for persistent objects (domains, networks,
etc.) and we don't need other users to read/write those files.
But shortly, this function is going to be used for creating files
for QEMU domains. There we want the QEMU process (i.e. different
user) to read the file.
Therefore, introduce two new arguments: @uid and @gid that allow
setting desired owner of the file. Pass -1 to preserve current
behaviour (i.e. create the file owned by the user running the
daemon).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We try to update vlan tag by running virsh update-device command,
libvirtd will report ovs-vsctl arguments error. Vlan tag update
funtion does't consider the xml with no vlan configured circumstances.
The steps to reproduce the problem:
1 define and start domain with its vlan configured as:
<interface type='bridge'>
<mac address='52:54:00:9e:bb:ac'/>
<source bridge='ovs-br0'/>
<vlan>
<tag id='10'/>
</vlan>
<virtualport type='openvswitch'>
</virtualport>
<target dev='vnet4.0'/>
<model type='virtio'/>
<driver name='vhost'/>
</interface>
2 define and run virsh update-device command with no vlan configured as:
<interface type='bridge'>
<mac address='52:54:00:9e:bb:ac'/>
<source bridge='ovs-br0'/>
<virtualport type='openvswitch'>
</virtualport>
<target dev='vnet4.0'/>
<model type='virtio'/>
<driver name='vhost'/>
</interface>
#virsh update-device dom-id novlan.xml
3 virsh command returned error, and we got an error in libvirtd.log:
error : virCommandWait:2584 : internal error: exit status 1: ovs-vsctl: 'set' command requires at least 3 arguments
. Child process (ovs-vsctl --timeout=5 -- --if-exists clear Port vnet4.0 tag -- --if-exists clear Port vnet4.0 trunk
-- --if-exists clear Port vnet4.0 vlan_mode -- --if-exists set Port vnet4.0) unexpected
error : virNetDevOpenvswitchUpdateVlan:540 : internal error: Unable to set vlan configuration on port vnet4.0
Signed-off-by: Tu Qiang <tu.qiang35@zte.com.cn>
Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This change was generated using the following spatch:
@ rule1 @
expression a;
identifier f;
@@
<...
- f(*a);
... when != a;
- *a = NULL;
+ g_clear_pointer(a, f);
...>
@ rule2 @
expression a;
identifier f;
@@
<...
- f(a);
... when != a;
- a = NULL;
+ g_clear_pointer(&a, f);
...>
Then, I left some of the changes out, like tools/nss/ (which
doesn't link with glib) and put back a comment in
qemuBlockJobProcessEventCompletedActiveCommit() which coccinelle
decided to remove (I have no idea why).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function will attempt to read a pid from @path, and store it in
@pid. The @pid will only be set, however, if @path is locked by
virFileLock() at byte 0 and the pid in @path is running.
Signed-off-by: Vasiliy Ulyanov <vulyanov@suse.de>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
SmartNIC DPUs may not expose some privileged eswitch operations
to the hypervisor hosts. For example, this happens with Bluefield
devices running in the ECPF (default) mode for security reasons. While
VF MAC address programming is possible via an RTM_SETLINK operation,
trying to set a VLAN ID in the same operation will fail with EPERM.
The equivalent ip link commands below provide an illustration:
1. This works:
sudo ip link set enp130s0f0 vf 2 mac de:ad:be:ef:ca:fe
2. Setting (or clearing) a VLAN fails with EPERM:
sudo ip link set enp130s0f0 vf 2 vlan 0
RTNETLINK answers: Operation not permitted
3. This is what Libvirt attempts to do today (when trying to clear a
VF VLAN at the same time as programming a VF MAC).
sudo ip link set enp130s0f0 vf 2 vlan 0 mac de:ad:be:ef:ca:fe
RTNETLINK answers: Operation not permitted
If setting an explicit VLAN ID results in an EPERM, clearing a VLAN
(setting a VLAN ID to 0) can be handled gracefully by ignoring the
EPERM error with the rationale being that if we cannot set this state
in the first place, we cannot clear it either.
In order to keep explicit clearing of VLAN ID working as it used to
be passing a NULL pointer for VLAN ID is used.
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There should be a way to show no intent in programming a VLAN at all
(including clearing it). This allows handling error conditions
differently when VLAN clearing is explicit (vlan id == 0) vs implicit
(vlanid == NULL - try to clear it if possible).
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This has a benefit of being able to handle error codes for those
operations separately which is useful when drivers allow setting a MAC
address but do not allow setting a VLAN (which is the case with some
SmartNIC DPUs).
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Some files do not include what they use and rely on virutil.h
to pull in the necessary header files.
Fix it.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
Identifies all of various MIPS sub-architectures: 32-bit or 64-bit,
little-endian or big-endian.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There are few places where the g_steal_pointer() is open coded.
Switch them to calling the g_steal_pointer() function instead.
Generated by the following spatch:
@ rule1 @
expression a, b;
@@
<...
- b = a;
... when != b
- a = NULL;
+ b = g_steal_pointer(&a);
...>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Modeled after "WITH_QEMU_LOCK_GUARD" (see qemu's include/qemu/lockable.h).
See comment for typical usage.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Typical usage:
void foobar(virObjectLockable *obj)
{
VIR_LOCK_GUARD lock = virObjectLockGuard(obj);
/* `obj` is locked, and released automatically on scope exit */
...
}
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Modeled after "WITH_QEMU_LOCK_GUARD" (see qemu's include/qemu/lockable.h).
See comment for typical usage.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Locks a virMutex on creation and unlocks it in its destructor.
The VIR_LOCK_GUARD macro is used instead of "g_auto(virLockGuard)" to
work around a clang issue (see https://bugs.llvm.org/show_bug.cgi?id=3888
and https://bugs.llvm.org/show_bug.cgi?id=43482).
Typical usage:
void function(virMutex *m)
{
VIR_LOCK_GUARD lock = virLockGuardLock(m);
/* `m` is locked, and released automatically on scope exit */
...
while (expression) {
VIR_LOCK_GUARD lock2 = virLockGuardLock(...);
/* similar */
}
}
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Remove pointless 'ret', cmd variable reuse and use g_auto.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use g_auto, split the double use of 'cmd' variable and remove useless
ret variable.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Separate the two uses of 'cmd' to avoid mixing manual and automatic
cleanup.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reduce the scope of the variable to avoid renaming it.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use automatic cleanup and remove the 'ret' variable in favor of
direct returns.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In case virXMLPropUInt() or virXMLPropULongLong() meets an
attribute with a negative integer the following error message is
printed:
Invalid value ...: Expected integer value
This message is not as good as it could be. Let users know it's a
non-negative integer we are expecting.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This reverts commit 938382b60a.
Turns out, the commit did more harm than good. It changed
semantics on some public APIs. For instance, while
qemuDomainGetInfo() previously did not returned an error it does
now. While the calls to virProcessGetStatInfo() is guarded with
virDomainObjIsActive() it doesn't necessarily mean that QEMU's
PID is still alive. QEMU might be gone but we just haven't
realized it (e.g. because the eof handler thread is waiting for a
job).
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2041610
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
We're currently passing '0' which leaves the syslog facility
unset. Since we're passing an explicit facility for syslog
when using journald, it makes sense to be explicit when
using syslog directly too.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We set SYSLOG_PRIORITY when sending to journald to avoid our
messages getting tagged with the default facility which is
used for the kernel.
Unfortunately:
commit fd00f0e6c7
Author: Guido Günther <agx@sigxcpu.org>
Date: Mon Sep 21 20:06:55 2015 +0200
Use daemon log facility for journald
used the LOG_nnn constants from the syslog header without realizing
that these values have a bit-shift applied. While Linux defines a
LOG_FAC() macros to undo the bit-shift this doesn't appear to be
standardized. So the safe thing is to just use the raw value since
these values are fixed by RFC 5424.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
It was only used to construct the hash key for the (now removed)
shared devices in the qemu driver.
Remove it and its mocking.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
unpriv_sgio was a downstream-only feature in RHEL 6-8.
The libvirt support was merged upstream by mistake.
Remove the function that constructs the sysfs path and assume it
does not exist in all the callers.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The virNetDevOpenvswitchInterfaceSetQos function is uneven
because setting the Rx Qos is open-coded, while clearing it
is sepearated in another function.
Separate the setting too.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The virNetDevOpenvswitchInterfaceSetQos function is uneven
because setting the Tx Qos is open-coded, while clearing it
is sepearated in another function.
Separate the setting too.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
These functions are called by virNetDevOpenvswitchInterfaceSetQos
as well as virNetDevOpenvswitchInterfaceClearQos.
Move them above both fuctions.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We don't do anything with it after checking that it satisfies our
requirements and don't provide a way for users of the module to
access it, so carrying it around is pointless.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
After previous cleanups, there's just one caller of
dnsmasqCapsNewEmpty() and it is dnsmasqCapsNewFromBinary().
And the former is pretty short. Therefore, it is not necessary
for the code to live in two separate functions. Dissolve the
former in the latter.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
First observation: There is no way that caps->binaryPath can be
NULL. Second observation: There is no caller that passes NULL.
Let's drop the ternary operator and access @caps directly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
While it's true that our virCommand subsystem is happy with
non-absolute paths, the dnsmasq capability code is not. It stores
the path to dnsmasq within and makes it accessible via
dnsmasqCapsGetBinaryPath(). While strictly speaking no caller
necessarily needs canonicalized path, let's find dnsmasq once and
cache the result.
Therefore, when constructing the capabilities structure look up
the binary path. If DNSMASQ already contains an absolute path
then virFindFileInPath() will simply return a copy.
With this code in place, the virFileIsExecutable() check can be
removed from dnsmasqCapsRefreshInternal() because
virFindFileInPath() already made sure the binary is executable.
But introducing virFindFileInPath() means we have to mock it in
test suite because dnsmasqCaps are created in
networkxml2conftest.
Moreover, we don't need to check for dnsmasq in configure.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
We don't query any capabilities of dnsmasq. We are only
interested in dnsmasq's version (obtained via 'dnsmasq
--version'). Therefore, there's no point in running 'dnsmasq
--help'. Its output is not processed even.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
There is no way that the dnsmasqCapsRefreshInternal() function
can be called with @caps == NULL. Therefore, drop the if() that
checks for that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The noRefresh member of _dnsmasqCaps struct is set only after it
was checked for and is never checked again. This is needless and
the member can be removed. There is no way that
dnsmasqCapsRefreshInternal() can be called after
dnsmasqCapsSetFromBuffer().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The _dnsmasqCaps struct has @mtime member which holds the mtime
of the dnsmasq binary. The idea was that capabilities don't need
to be queried if mtime hasn't changed since the last time.
However, the code that would try to query capabilities again was
removed and now we are left with code that stores mtime but has
no use for it.
Remove the member and code that uses it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This argument is not used really as the only caller passes true
and dnsmasqCapsRefreshInternal() only checks for false value.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The dnsmasqCaps type has its own cleanup function defined and
ready to use via g_autoptr(). Use automatic cleanup instead of
an explicit one.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Both callers of dnsmasqCapsNewEmpty() pass DNSMASQ as an argument
which is then fed to a ternary operator which looks like this
(after substitution).
DNSMASQ ? DNSMASQ : DNSMASQ
While I like tautologies, the code can be simplified by dropping
the argument.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The way that virConfSetValue() works (and the way it is even
documented) is that the @value pointer is always consumed.
However, since the first order pointer is passed it leaves
callers in a pickle situation - they always have to set pointer
to NULL after calling virConfSetValue() to avoid touching it.
Let's switch @value to a double pointer and clear it inside the
function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This commit declares g_autoptr() function for virConfValue type.
At the same time, it switches variable declarations to use it.
Also, in a few places we might have freed a variable twice, for
instance in xenFormatXLDomainNamespaceData(). This is because
virConfSetValue() consumes passed pointer (@value) even in case
of failure and thus any code that uses virConfSetValue() must
refrain from touching @value and it must not call
virConfFreeValue().
This semantic is not obvious and will be addressed in one of
future commits.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Callers of virConfSetValue() don't report any error, they just
pass the error blindly. Therefore, report an error when
virConfSetValue() is about to fail.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently virProcessGetStatInfo() always returns success and only logs error
when it is unable to parse the data. Make this function actually report the
error and return a negative value in this error scenario.
Fix the callers so that they do not override the error generated.
Also fix non-linux implementation of this function so as to report error.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There are a few glib functions that abort on OOM and thus there's
no point in checking their retval against NULL. Nevertheless, we
do have those checks in a few places. Remove them.
Generated using the following spatch:
@@
expression x;
identifier n;
expression r;
@@
(
x = g_strdup_printf(...);
| x = g_strdup_vprintf(...);
| x = g_strdup(...);
| x = g_strndup(...);
| x = g_new0(...);
| x = g_realloc(...);
)
... when != x
- if(!x)
(
- return r;
|
- goto n;
)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Both virProcessGetStatInfo() and virProcessGetSchedInfo() are
Linux centric. Provide stubs for non-Linux platforms.
Fixes: d73852c499
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virURIParamAppend() unconditionally returns 0. Simplify and make the return type
as void type.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Move qemuGetProcessInfo and qemuGetSchedInfo methods to util and share them
with ch driver.
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
And make callers check the return value as well. This helps error out early for
invalid environment variables.
That is desirable because it could lead to deadlocks. This can happen when
resetting logging after fork() reports translated errors because gettext
functions are not reentrant. Well, it is not limited to resetting logging after
fork(), it can be any translation at that phase, but parsing environment
variables is easy to make fail on purpose to show the result, it can also happen
just due to a typo.
Before this commit it is possible to deadlock the daemon on startup
with something like:
LIBVIRT_LOG_FILTERS='1:*' LIBVIRT_LOG_OUTPUTS=1:stdout libvirtd
where filters are used to enable more logging and hence make the race less rare
and outputs are set to invalid
Combined with the previous patches this changes
the following from:
...
<deadlock>
to:
...
libvirtd: initialisation failed
The error message is improved in future commits and is also possible thanks to
this patch.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This prevents starting any daemons with improper logging settings. This is
desirable on its own, but will be even more beneficial when more functions start
reporting errors and failing on them, coming up in following patches
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The only difference is that we are not going to be guaranteed that the mutex is
normal (as opposed to recursive, although there is no system known to me that
would default to recursive mutexes), but that was done only to find occasional
errors (during runtime, back in 2010, commit 336fd879c0). Functions using
this mutex are mostly stable and unchanging, and it makes the virLogOnceInit()
function only return 0 (or possibly abort in glib calls). On top of that we can
assume that the virLogMutex is always initialized which enables us to be more
consistent in some early error reporting.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
As described in the previous commit, the units for 'burst' are
kibibytes and not kilobytes, i.e. multiples of 1024 not 1000.
Therefore, when constructing ovs-vsctl command the burst value
must be multiplied by 1024 and not just 1000. And because ovs
expects this size in bits the value has to be multiplied again by
8.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1510237#c26
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The burst attribute for bandwidth specifies how much bytes can be
transmitted in a single burst. Therefore, the unit is in
multiples of 1024 (thus kibibytes) not SI-like 1000. It has
always been like that.
The 'tc' output is still confusing though, for instance:
# tc class add dev $DEV parent 1: classid 1:1 htb rate 1000kbps burst 2097152
# tc class show dev vnet2
class htb 1:1 root rate 8Mbit ceil 8Mbit burst 2Mb cburst 1600b
Please note that 2097152 = 2*1024*1024. Even the man page is
confusing. From tc(8):
kb or k Kilobytes
mb or m Megabytes
But I guess this is because 'tc' predates IEC standardisation of
binary multiples and thus can't change without breaking scripts
parsing its output.
And while at it, adjust _virNetDevBandwidthRate struct member
description, to make it obvious which members use SI/IEC units.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The new helper replaces the 'value' part of the key-value tuple in an
object. The advantage of this new helper is that it preserves the
ordering of the key in the object when compared to a combination of
stealing the old key and adding a new value. This will be needed for a
new test/helper for validating and modifying qemu capabilities data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If needed 'virJSONValueIsNull' can be easily replaced by
'virJSONValueGetType(obj) == VIR_JSON_TYPE_NULL'.
'virJSONValueObjectIsNull' has confusing name because it checks that a
virJSONValue of OBJECT type has a key which is NULL, not that the object
itself is NULL. This can be replaced according to the needs e.g. by
virJSONValueObjectHasKey or the above check.
Both are unused.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Replace the function by a call to virJSONValueNewString, when we copy
the string using g_strndup. Remove the unused helper.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
