This makes it possible to call virCPUDataParse with a xmlNodePtr,
which will be required by a later patch.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The function does not need a full xmlXPathContextPtr any longer and a
later patch will require a call to this function with only a xmlNodePtr
available.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Factor out duplicated code from x86FeatureParse and virCPUx86DataParse.
This also consolidates error messages.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
... by using virXMLProp*() helpers. These only require a xmlNodePtr and
do not need a xmlXPathContextPtr. Reflect that in the function signature.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
... by using virXMLProp*() helpers. These only require a xmlNodePtr and
do not need a xmlXPathContextPtr. Reflect that in the function signature.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When I was cleaning up the regex after we removed most of our custom
autofree helpers I've forgot to delete one closing brace, thus the regex
was not matching anything.
Fixes: 65f702020e
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If there is no tcp_min_ssf value set in daemon config we still
compare it against the default (56 which corresponds to DES) and
if the value is below our expected minimum (112 which corresponds
to 3DES) an error is reported and the daemon refuses to start.
This is not what we want. What we want is to check the value iff
the value was specified in the config file.
Fixes: 58a48cff84
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Support return guest interface information from guest agent
Signed-off-by: zhanglei <zhanglei@smartx.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
The new parameter group returns information about network interfaces
Signed-off-by: zhanglei <zhanglei@smartx.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
1) 'activePcrBanksStr' is not initialized:
../../../libvirt/src/qemu/qemu_tpm.c: In function ‘qemuExtTPMStart’:
/usr/include/glib-2.0/glib/glib-autocleanups.h:28:3: error: ‘activePcrBanksStr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
28 | g_free (*pp);
| ^~~~~~~~~~~~
../../../libvirt/src/qemu/qemu_tpm.c:613:22: note: ‘activePcrBanksStr’ was declared here
613 | g_autofree char *activePcrBanksStr;
| ^~~~~~~~~~~~~~~~~
2) 'pwdfile_fd' is unused:
../../../libvirt/src/qemu/qemu_tpm.c:615:19: error: unused variable 'pwdfile_fd' [-Werror,-Wunused-variable]
VIR_AUTOCLOSE pwdfile_fd = -1;
Fixes: a5bbe1a8b6
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
It won't cause any harm as cpus is NULL when we pass a negative ncpus,
but doing so when the function expects unsigned value is not right.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The return value was not properly checked in the code for input type
evdev.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Extend the TPM backend XML with a node 'active_pcr_banks' that allows a
user to specify the PCR banks to activate before starting a VM. Valid
choices for PCR banks are sha1, sha256, sha384 and sha512. When the XML
node is provided, the set of active PCR banks is 'enforced' by running
swtpm_setup before every start of the VM. The activation requires that
swtpm_setup v0.7 or later is installed and may not have any effect
otherwise.
<tpm model='tpm-tis'>
<backend type='emulator' version='2.0'>
<active_pcr_banks>
<sha256/>
<sha384/>
</active_pcr_banks>
</backend>
</tpm>
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2016599
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
At this point, we're no longer using the availability of the
ZFS programs at build time to decide whether to enable ZFS
support, so the only purpose of these find_program() calls is
to record their absolute paths.
However, the virCommand facilities that we're ultimately using
to run them are already capable of performing this lookup at
runtime, and in fact that's exactly what we already do in the
case of, for example, vstorage.
Drop the build time lookups and always perform them at runtime.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Commit 73a2ff3616 already improved the situation a lot. This
pushes things even further.
If the user or, more likely, the distro packager explicitly
asked for ZFS support to be enabled, then we should comply with
that request regardless of whether the necessary programs are
available at build time.
This is particularly important in the context of Debian, where
ZFS cannot be a build dependency of libvirt due to licensing
issues but it can still be an optional runtime dependency.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Add an option to allow the admin to requet a higher minimum SSF
for connections than the built-in default.
The current default is 56 (single DES equivalent, to support
old kerberos) and will be raised to 112 in the future.
https://bugzilla.redhat.com/show_bug.cgi?id=1431589
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Store the minimum SSF value for TCP connections
in virNetSASLContext and introduce a getter for it.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Prepare for deprecating old kerberos ciphers by warning users
with a SSF lower than 112.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
It is now unused.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The presence of this capability depends on QEMU being compiled
with spice that has the SPICE_ADDR_FLAG_UNIX_ONLY constant.
It was added by spice commit 5365caeaae released in spice v0.12.6,
which is older than the spice version on our supported architectures.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
For later QEMUs than 2.11 we do FD passing for character devices,
so lock the capabilites to this exact version.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Move the test closer to other graphics-spice tests.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reduce the churn in following patches.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This commit aims to address the bug reported in [1] and [2].
If the profile is corrupted (0-size) the VM cannot be launched.
To overcome this, check if the profile exists and if it has 0 size
remove it.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890084
[2] https://bugs.launchpad.net/bugs/1927519
Signed-off-by: Ioanna Alifieraki <ioanna-maria.alifieraki@canonical.com>
Reviewed-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add stat entries also for the mirror destination and the backup job
scratch/target file. This is possible with '-blockdev' as we use unique
index for the entries.
The stats are reported when the VIR_CONNECT_GET_ALL_DOMAINS_STATS_BACKING
is used.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2017928
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the 'query-nodes' flag to return all stats. The flag was introduced
prior to qemu-2.11 so we can always use it, but we invoke it only when
querying stats. The other invocation is used for detecting the nodenames
which is fragile code.
The images without a frontend don't have the device field so the
extraction code checks need to be relaxed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The formatter for the backup job data didn't pass the virDomainXMLOption
struct to the disk formatter which meant that the private data of the
disk source were not formatted.
This didn't pose a problem for now as the blockjob list remembered the
nodenames for the jobs, but the backup source lost them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Presumably the result of a copy/paste mistake, the the argument for the
`nodedev-start` command was described as a 'network' rather than a
'device'.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
While being great semantic patching tool, coccinelle fails to
understand some of macros we use (including those provided by
glib). What they have in common is use of __attribute__ under the
hood. We store a list of such macros in a file. But in there,
g_auto() macro is not defined properly. Indeed, g_auto(type)
declares a local variable of given type, for instance from
cocci's POV:
g_auto(virBuffer) buf = VIR_BUFFER_INITIALIZER;
virBuffer buf = VIR_BUFFER_INITIALIZER;
are both the same declaration. Fix declaration of g_auto() stub.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
For statically declared arrays one can use G_N_ELEMENTS() instead
of explicit sizeof(array) / sizeof(item). I've noticed couple of
places where the latter was used.
I am not fixing every occurrence because we have some places
which do not use glib (examples and NSS module).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
In testPCIVPDResourceCustomCompareIndex() there are two variables
declared at one line. They are both g_autoptr() decorated which
makes it worse, because coccinelle fails to parse that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
I've noticed one function inside virpcivpd.c, namely
virPCIVPDParseVPDLargeResourceFields() that declares some
variables at the top level even though they are used only inside
a loop in which they have to be freed explicitly.
Bringing variable declarations into the loop allows us to make
the code nicer.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
I've noticed three functions inside node_device_conf.c, namely:
- virNodeDeviceCapVPDParseCustomFields()
- virNodeDeviceCapVPDParseReadOnlyFields()
- virNodeDeviceCapVPDParseXML()
that have strange attitude towards g_auto* variables. The first
problem is that variables are declared at the top level despite
being used inside a loop. The second problem is use of g_free()
in combination with g_steal_pointer() even though we have
VIR_FREE() which does exactly that.
Bringing variable declarations into their respective loops allows
us to make the code nicer.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
The first part of the version string contains the name that the
rst2html5 command was invoked as, which can differ based on the
operating system: on FreeBSD, for example, it's rst2html5.py
instead of just rst2html5.
Fix our detection logic so that it works regardless of the
specific name used for the docutils-provided rst2html5 command.
Fixes: cf0c9e1865
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
This warning is emitted for pretty much every test case,
making it hard to see what the actual error is.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The test case should return -1, not 0 in case a valid resource could
not be parsed successfully but the ret value is initialized to 0.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
While invalid values need to be ignored when presenting VPD data to the
user, it would be good to attempt to parse a valid portion of the VPD
instead of marking it invalid as a whole.
Based on a mailing list discussion, the set of accepted characters is
extended to the set of printable ASCII characters.
https://listman.redhat.com/archives/libvir-list/2021-October/msg01043.html
The particular example encountered on real hardware was multi-faceted:
* "N/A" strings present in read-only fields. This would not be a useful
valid value for a field (especially if a unique serial number is
expected), however, it was decided to delegate handling of those kinds
of values to higher-level software;
* "4W/1W PCIeG2x4" - looks like some vendors use even more printable
characters in the ASCII range than we currently allow. Since the
PCI/PCIe VPD specs mention alphanumeric characters without specifying
the full character set, it looks like this is ambiguous for vendors
and they tend to use printable ASCII characters;
* 0xFF bytes present in VPD-W field values. Those bytes do not map to
printable ASCII code points and were probably used by the vendor as
placeholders. Ignoring the whole VPD because of that would be too
strict.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
* RV and RW fields must be at the last position in their respective
section (per the conditions in the spec). Therefore, the parser now
stops iterating over fields as soon as it encounters one of those
fields and checks whether the end of the resource has been reached;
* The lack of the RW field is not treated as a parsing error since we
can still extract valid data even though this is a PCI/PCIe VPD spec
violation;
* Individual fields must have a valid length - the parser needs to check
for invalid length values that violate boundary conditions of the
resource.
* A zero-length field may be the last one in the resource, however, the
boundary check is currently too strict to allow that.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
There are a lot of places where we call virInterfaceDefFree()
explicitly. We can define autoptr cleanup macro and annotate
declarations with g_autoptr() and remove plenty of those explicit
free calls.
This also fixes a memory leak in udevInterfaceGetXMLDesc() which
called virInterfaceDefFree() only in successful path.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
