Eliminate cleanup code by using g_autofree.
Signed-off-by: Yi Li <yili@winhong.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Looking at the entire repository reveals we're not too consistent
about this, but at least in this specific document we mostly have
two blank lines between sections, so let's stick with that.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
In recent commit v6.8.0-135-g518be41aaa the formatting of NBD
into migration cookie was moved into a separate function and with
it it was switched from direct printing into the output buffer to
virXMLFormatElement(). But there was a typo. The
virXMLFormatElement() accepts two buffers on input, one for
element attributes and another for child elements. Well, the line
that was supposed to add NBD port into the attributes buffer
printed the attribute directly into the output buffer which
produced this mangled XML:
<qemu-migration>
port='49153'<nbd>
<disk target='vda' capacity='8589934592'/>
<disk target='vdb' capacity='12746752000'/>
</nbd>
</qemu-migration>
Changing the incriminated line to print into the attributes
buffer fixes the problem.
Fixes: 518be41aaa
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In one of recent patches the way that we start NBD server for
incoming migration was reworked (v6.8.0-rc1~298). A new boolean
was introduced that tracks whether the NBD server was started so
that we don't start it twice nor record in the port in the port
allocator twice. Well, this idea is good, but in the
implementation the boolean is never set, so we are reserving the
port twice and would be starting the NBD server twice too if it
wasn't for port reservation fail.
Fixes: e74d627bb3
Reported-by: Vjaceslavs Klimovs <vklimovs@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Guests should be allowed to create hard links on mounted pathes, since
many applications rely on this functionality and would error on guest
with current "rw" AppArmor permission with 9pfs.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In qemuDomainLogContextNew() the domain log file is opened.
Twice, the first time for writing, and the second time for
reading (if required by caller). When opening the log file for
reading a mode is provided. This doesn't do much harm, but is
unnecessary. Drop the mode.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The current udev node device driver ignores all events related to vdpa
devices. Since libvirt now supports vDPA network devices, include these
devices in the device list.
Example output:
virsh # nodedev-list
[...ommitted long list of nodedevs...]
vdpa_vdpa0
virsh # nodedev-dumpxml vdpa_vdpa0
<device>
<name>vdpa_vdpa0</name>
<path>/sys/devices/vdpa0</path>
<parent>computer</parent>
<driver>
<name>vhost_vdpa</name>
</driver>
<capability type='vdpa'>
<chardev>/dev/vhost-vdpa-0</chardev>
</capability>
</device>
NOTE: normally the 'parent' would be a PCI device instead of 'computer',
but this example output is from the vdpa_sim kernel module, so it
doesn't have a normal parent device.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Trivial fix to improve readability by combining these into a compound
conditional.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
Coverity reported a potential resource leak. While it's probably not
a real-world scenario, the code could technically jump to cleanup
between the time that vdpafd is opened and when it is used. Ensure that
it gets cleaned up in that case.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
The change re-introduces f6d6086dbf ("tests: Make references to global
symbols indirect in test drivers") that got lost during meson
conversion.
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Commit d6b17edd51 ("tests: Lookup extended stat/lstat in mocks")
adds support for mocking of stat() and lstat() on macOS.
The change was broken because virmockstathelpers.c only follows glibc
logic and MOCK_STAT and MOCK_LSTAT are not getting defined on macOS.
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There is a typo that prevents initialization of real_lstat.
Fixes: d6b17edd51 ("tests: Lookup extended stat/lstat in mocks")
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Since QEMU 5.2 (commit-77b285f7f6), QEMU supports 'memory failure'
event, posts event to monitor if hitting a hardware memory error.
Fully support this feature for QEMU.
Test with commit 'libvirt: support memory failure event', build a
little complex environment(nested KVM):
1, install newly built libvirt in L1, and start a L2 vm. run command
in L1:
~# virsh event l2 --event memory-failure
2, run command in L0 to inject MCE to L1:
~# virsh qemu-monitor-command l1 --hmp mce 0 9 0xbd000000000000c0 0xd 0x62000000 0x8c
Test result in l1(recipient hypervisor case):
event 'memory-failure' for domain l2:
recipient: hypervisor
action: ignore
flags:
action required: 0
recursive: 0
Test result in l1(recipient guest case):
event 'memory-failure' for domain l2:
recipient: guest
action: inject
flags:
action required: 0
recursive: 0
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Introduce memory failure event. Libvirt should monitor domain's
event, then posts it to uplayer. According to the hardware memory
corrupted message, a cloud scheduler could migrate domain to another
health physical server.
Several changes in this patch:
public API:
include/*
src/conf/*
src/remote/*
src/remote_protocol-structs
client:
examples/c/misc/event-test.c
tools/virsh-domain.c
With this patch, each driver could implement its own method to run
this new event.
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This is mostly opening hyperv driver sources in vim, selecting
everything, hitting reformat and then fixing a very few places.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Matt Coleman <matt@datto.com>
In some places we separate functions with only one line, in
others with three lines and the rest uses two lines.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Matt Coleman <matt@datto.com>
A few commits ago, hypervRequestStateChange() helper was
introduced which has exactly the same code as a part of
hypervDomainSuspend(). Deduplicate by calling the helper.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Matt Coleman <matt@datto.com>
The hypervCreateInvokeParamsList() function sets an error on a
failure, therefore there is no need to report another error in
callers.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Matt Coleman <matt@datto.com>
Since we use virHashTable for string-keyed values only, we can remove
all the callbacks which allowed universal keys.
Code which wishes to use non-string keys should use glib's GHashTable.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
All users of virHashTable pass strings as the name/key of the entry.
Make this an official requirement by turning the variables to 'const
char *'.
For any other case it's better to use glib's GHashTable.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The only place we call it is in virHashNew. Move the code to virHashNew
and remove virHashCreateFull.
Code wishing to use non-strings as hash table keys will be better off
using glib's GHashTable directly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
It doesn't make much sense to configure the bucket count in the hash
table for each case specifically. Replace all calls of virHashCreate
with virHashNew which has a pre-set size and remove virHashCreate
completely.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
virHashCreate will be removed in upcoming patches. This change has an
impact on ordering of the blockjob entries in one of the status XML->XML
tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Most callers pass a random number. We have virHashNew which doesn't give
the callers the option to configure the table. Since we are going to
switch to virHashNew replace it in tests and remove multiple instances
of the 'testHashGrow' case as it doesn't make sense with the new
semantics.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Export the freeing function rather than having a wrapper for the hash
creation function.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Rewrite using GHashTable which already has interfaces for using a number
as hash key.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Remove 'cleanup' label and simplify remembering of the returned value
from the callback.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Rewrite using GHashTable which already has interfaces for using a number
as hash key. Glib's implementation doesn't copy the key by default, so
we need to allocate it, but overal the interface is more suited for this
case.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
It's used only in one place in tests which isn't even automatically
evaluated.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
virCgroupKillRecursive sneakily initializes 'ret' to 0 rather than the
usual -1. 401030499b moved an error condition but didn't actually
modify 'ret' return the proper error code.
Fixes: 401030499b
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The @canonical_path variable holds canonicalized path passed as
argv[1]. The canonicalized path is obtained either via
virFileResolveLink() or plain g_strdup(). Nevertheless, in both
cases it must be freed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Some functions called from parthelper can report an error. But
that means that the error object must be initialized otherwise
virResetError() (which happens as a part of virReportError())
will free random pointers.
Reported-by: Katerina Koukiou <kkoukiou@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use of the -enable-fips option is being deprecated in QEMU >= 5.2.0. If
FIPS compliance is required, QEMU must be built with libcrypt which will
unconditionally enforce it.
Thus there is no need for libvirt to pass -enable-fips to modern QEMU.
Unfortunately there was never any way to probe for -enable-fips in the
first instance, it was enabled by libvirt based on version number
originally, and then later unconditionally enabled when libvirt dropped
support for older QEMU. Similarly we now use a version number check to
decide when to stop passing -enable-fips.
Note that the qemu-5.2 capabilities are currently from the pre-release
version and will be updated once qemu-5.2 is released.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Rename 'FLAG_FIPS' to 'FLAG_FIPS_HOST' to signify that we are simulating
a host supporting fips mode and use the flag to assert 'enabeFips'
argument of 'qemuProcessCreatePretendCmdBuild' rather than passing it
via QEMU_CAPS_ENABLE_FIPS.
This prepares the testsuite for testing of -enable-fips deprecation in
qemu-5.2.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
virPCIDeviceAddressGetSysfsFile() is simpler to call.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
These were nops once enough cleanup was g_auto'd.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
thisPhysPortID is only used inside a conditional, so reduce its scope
to just the body of that conditional, which will eliminate the need
for the undesirable manual VIR_FREE().
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This function had a loop that was only executed twice; it was
artificially constructed with a label, a goto, and a boolean to tell
that it had already been executed once. Aside from that, the body of
the loop contained only two lines that needed to be repeated (the
second time through, everything beyond those two lines would be
skipped).
One side effect of this strange loop was that a g_autofree string was
manually freed and re-initialized; I've been told that manually
freeing a g_auto_free object is highly discouraged.
This patch refactors the function to simply repeat the 2 lines that
might possibly be executed twice, thus eliminating the ugly use of
goto to construct a loop, and also takes advantage of the fact that
virPCIDriverDir() was previously returning *exactly* the same string
both times it was called to eliminate the manual VIR_FREE of drvpath.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There is no need for a temporary variable in this function, and since
it can't return NULL, no need for callers to check for it.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There is no need for a temporary variable in this function, and ever
since we switched to glib for memory allocation, there is no possibility
it can return NULL, so callers don't need to check for it.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Apparently at some point in the past, when there were multiple types
to represent PCI addresses, the function
virPCIDeviceAddressGetSysfsFile() used one of those types, while
virDomainHostDevDef used another. It's been quite awhile since we
reduced the number of different representations of PCI address, but
this function was still creating a temporary virPCIDeviceAddress, then
copying the individual elements into this temporary object from the
same type of object in the virDomainHostDevDef.
This patch just eliminates that pointless copy.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When this function was recently changed to add in parsing of
IFLA_VF_STATS, I noticed that the checks for existence of IFLA_VF_MAC
and IFLA_VF_VLAN were looking in the *wrong array*. The array that
contains the results of parsing each IFLA_VFINFO in
tb[IFLA_VFINFO_LIST] is tb_vf, but we were checking for these in tb
(which is the array containing the results of the toplevel parsing of
the netlink message, *not* the results of parsing one of the nested
IFLA_VFINFO's.
This incorrect code has been here since the function was originally
written in 2012. It has only worked all these years due to coincidence
- the items at those indexes in tb are IFLA_ADDRESS and IFLA_BROADCAST
(of the *PF*, not of any of its VFs), and those happen to always be
present in the toplevel netlink message; since we are only looking in
the incorrect place to check for mere existence of the attribute (but
are doing the actual retrieval of the attribute from the correct
place), this bug has no real consequences other than confusing anyone
trying to understand the code.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
