Fix incorrect log message for timestamp value.
Probably this line was copied from the check for attr.
Found by Linux Verification Center (linuxtesting.org).
Fixes: 7cfb7aab57 ("security_util: Remove stale XATTRs")
Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Convert prototype of virFileLinkPointsTo to return bool.
Remove dead checks in virDomainObjListLoadConfig and
virNetworkLoadConfig.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
DO_TEST_CPUID(arch, host, json) is a multipart test. It consists of the
following tests:
- cpuTestHostCPUID()
- cpuTestGuestCPUID(with JSON_* flag)
- cpuTestCPUIDSignature()
- DO_TEST_JSON():
- if json==JSON_MODELS:
- cpuTestGuestCPUID(without JSON_* flag)
- cpuTestJSONCPUID()
- cputestJSONSignature()
Notice that for tests with json==JSON_MODELS, cpuTestGuestCPUID() is
actually called twice but with different arguments. The first one passes
JSON_MODELS to the test function, while the second one passes 0.
The main difference in behavior when calling cpuTestGuestCPUID() with or
without the flag is that in the first case, it parses the captured qemu
output from $ARCH-cpuid-$CPU.json. It extracts the cpu model list from
that JSON, and uses that to filter out possible cpu models to match.
In other words, it tries to match the cpu to a model that was supported
by the qemu version that was used to generate this JSON file. When it
finds a match, it generates a cpu definition and compares the xml form
of that definition with the file $ARCH-cpuid-$CPU-guest.xml.
When called without the JSON_MODELS flag, it simply attempts to match it
against the full libvirt cpu map and doesn't attempt to filter out any
matches based on the JSON qemu cpu model list. After it finds a match,
it generates an xml definition for the cpu and compares it to the same
file listed above. So if these two invocations disagree on the cpu match
(e.g. because libvirt has added a cpu model to its cpu map that matches
better than one that was supported by the version of qemu that generated
the JSON file) the test will fail.
This duplicate call to cpuTestGuestCPUID() was originally added in
commit 49c945a6f5. The original
justification for that commit was to fix test failures when the Qemu
driver was disabled. But since DO_TEST_JSON() is #defined empty when
qemu is disabled, this particular invocation would not even be executed
in this scenario, so it doesn't seem relevant.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If libvirt is built in client only mode, the libvirtd/virtqemud/etc
daemons won't exist. If the client is told to connect to a local
hypervisor, it'll see the socket doesn't exist, try to spawn the
daemon and then re-try connecting to the socket for a few seconds.
Ultimately this will fail because the daemon doesn't exist and the
user gets an error message
error: Failed to connect socket to '/run/user/1000/libvirt/virtqemud-sock': No such file or directory
technically this is accurate, but it doesn't help identify the root
cause. With this change it will now report
error: binary 'virtqemud' does not exist in $PATH: No such file or directory
and will skip all the socket connect retries
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
On device-update, when user requests change of
trustGuestRxFilters we currently do nothing. Nor error out, nor
act on the request. While we can just throw an error,
implementing this is pretty trivial.
Resolves: https://issues.redhat.com/browse/RHEL-735
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Sometimes it may be handy to just issue the query-rx-filter
monitor command without actually parsing the output. Adapt
qemuMonitorJSONQueryRxFilter() to this behavior.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When cold plugging a memory device we check whether there's
enough free memory slots to accommodate new module. Well, this
checks makes sense only for those memory devices that are plugged
into DIMM slots (DIMM and NVDIMM models). Other memory device
models, like VIRTIO_MEM, VIRTIO_PMEM or SGX_EPC are attached into
PCI bus, or no bus at all.
Resolves: https://issues.redhat.com/browse/RHEL-15480
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The code that handles coldplug of a memory device is pretty
trivial and such could continue to live in the huge switch()
where other devices are handled. But the code is about to get
more complicated. To help with code readability, move it into a
separate function.
And while at it, make the function accept a double pointer to the
memory device definition to make the ownership transfer obvious
(the device is part of the domain on successful run).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
For the xpath "/domain/cpu/@mode", it will return a list type not a
string. Use string() method in the xpath for the string result.
Fixes: 6b95437c17
Signed-off-by: Han Han <hhan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
All BuildRequires should now be part of the build environment,
so it's no longer needed.
This ensures that, if we forget to add some BuildRequires to the
build environment in the future, the mistake will be quickly
detected.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We currently have a BuildDepends on it, which doesn't help
ensuring that the tool is available at runtime, when the storage
driver might need to spawn it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We only use it at runtime, not during the build process.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We only use it at runtime, not during the build process.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We only use it at runtime, not during the build process.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
They've been there since the start, but we don't seem to be using
them for anything. The native part doesn't have BuildRequires on
the native equivalents.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The fact that we use an external search provider instead of a
built-in search functionality might come as a surprise to users,
and some of them might not be comfortable with the arrangement.
Mention it in the search interface to avoid surprises.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Ideally we'd just perform the search ourselves, but as long as
we have to rely on an external provider, at least make it a
somewhat privacy-conscious one.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Having the name of the project as part of the prefix was useful
back when we used the mailing list for all subprojects, but
these days the only patches that are sent to the list are for
the main library so it no longer makes sense to include this.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The VIR_PCI_DEVICE_ADDRESS_FMT macro is used only in virpci.c and
nowhere else. It's not necessary to expose it in the header file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When building a hostdev props, its PCI address is formatted via
g_strdup_printf(VIR_PCI_DEVICE_ADDRESS_FMT, ...); Well, we have a
function that does exactly that: virPCIDeviceAddressAsString().
Use the latter.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The VIR_PF_PHYS_PORT_NAME_REGEX macro is used only in
virPCIGetNetName() and nowhere else. It's not necessary to expose
it in the header file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The hotplug functionality added earlier really supports only live
addition of devices, no coldplug yet rendering @devConf in
testDomainAttachDeviceLiveAndConfig() an unused variable. Remove
it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Add a basic support for hotplug and hotunplug of PCI
<hostdev/>-s.
Signed-off-by: Thanos Makatos <thanos.makatos@nutanix.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The generator can produce different code on Linux and macOS:
specifically, on the former we want to use xdr_uint64_t while
the latter needs xdr_u_int64_t instead.
This is clearly a problem for tests that involve comparing the
output produced against some expected output that's stored in
the git repository.
In the long run, we need to find a better way to handle this,
but since 9.10.0 is going to be released very soon and we don't
want it to have a broken test suite on macOS, simply skip the
generator tests on that platform for now.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
macOS XDR library is an oddball using xdr_u_int64_t instead of
xdr_uint64_t which everyone else has.
The code generator already does the right thing, but the test
program previously generated with the Linux rpcgen program
does not compile on macOS due to this.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The test_demo program currently fails to compile on macOS with
too few arguments to function call, expected 3, have 2
ret = !!proc(&xdr, vorig);
~~~~ ^
Way back in 2013, commit 9fa3a8ab6f handled this situation
for the main library code. Apply the same fix here.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
These are currently the only tests that are not part of any
suite.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Some of the files used by test_demo.c can only be regenerated
when pytest is present, but we have pre-generated copies in the
repository, so overall we just need the C compiler to build and
run that specific test program.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.
Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/
Co-authored-by: Weblate <noreply@weblate.org>
Signed-off-by: Fedora Weblate Translation <i18n@lists.fedoraproject.org>
A bug in qemuProcessStartWithMemoryState caused that we would start qemu
with '-loadvm SNAP' and '-incoming defer' together. qemu doesn't expect
that and crashes on an assertion failure [1].
[1]: https://issues.redhat.com/browse/RHEL-16782
Fixes: 8a88d3e586
Resolves: https://issues.redhat.com/browse/RHEL-17841
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
There are some platforms where 'char' is unsigned, by default
(RPi, s390x to name a few). And because of how test_demo is
written we are experiencing some test cases failing there. For
instance: /xdr/struct-scalar is failing. This is because in the
test (test_struct_scalar()), we have a struct with two chars. One
is initialized to 0xca, the other 0xfe (note that both have the
MSB set). The XDR encoder (xdr_TestStructScalar()) then calls
xdr_char() on both of them. But XDR itself has no notion of
char type, so under the hood, it expands it to int [1] and calls
xdr_int(). And this is where the problem lies. On platforms where
char is signed, the integer expansion results in 0xffffffca, but
on platforms where char is unsigned it results in 0x000000ca. Two
distinct results.
The test then goes and compares the encoded buffer with an
expected one (memcmp(), read from the disk earlier).
This poses no problem for real life use, because when decoding
those chars back, the padding is thrown away.
To avoid tickling this issue, use values that don't have the MSB
set.
1: https://git.linux-nfs.org/?p=steved/libtirpc.git;a=blob;f=src/xdr.c;h=28d1382cc4853ecf1238d792af5016160435d1e0;hb=HEAD#l487
Fixes: 40cbaa8fbe rpcgen: add test case for XDR serialization
Reported-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
The test_demo program compares whether XDR encoded data match the
expected output as read from a file. But the file path is not
absolute and thus relative to CWD which means the program can run
only from one specific directory.
Do what we do in the rest of our test suite: define 'abs_srcdir'
macro and prefix the path with it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
During CH driver initialization (chStateInitialize()) the
driver's capabilities bitmap is allocated
(virCHCapsInitCHVersionCaps()), but corresponding free call is
missing in chStateCleanup().
And while at it, reorder calls to virObjectUnref() inside of
chStateCleanup() to be the reverse order of that in
chStateInitialize() so that it's easier to spot missing
free/unref call.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We no longer use it, so commit a62486b95f correctly dropped
the Build-Requires; shortly afterwards, however, I accidentally
reintroduced it by mistake.
Fixes: 3df8cc658e
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
