There's nothing special about the tests requiring to use very old
machine types. Most usage is cargo-culted from other tests. Switch all
the tests to use 'pc' instead.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For tests with fake capabilities we fill in a bunch of machine types
which the tests might use. For now there's a random collection of
machine types which are not actually used. Purge the unused ones for
non-x86 machines.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The two test cases were added to avoid regressions such as fixed in
17dff35848. Nowadays the code is much simpler and any Q35 machine
will trigger the explicit FDC.
Remove the '2.11' machine type version and turn the '2.9' version into a
generic q35 machine.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit c7f3a1f787 turned qemuDomainMachineNeedsFDC() effectively into
qemuDomainIsQ35. Use it instead as it also matches the non-canonicalized
'q35'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All the fd-passing setup of chardevs which this hack meant to disable
was moved to the host-preparation phase which is skipped for formatting
of non-real commandlines.
Signed-off-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>
Add domainGetVcpuPinInfo and nodeGetCPUMap callbacks to ch driver
Signed-off-by: Vineeth Pillai <viremana@linux.microsoft.com>
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>
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>
This change adds the domain name in the error and debug logs during
monitor IO processing so that we may infer which VM experienced
errors such as IO or socket hangup. This may help in debugging
monitor IO errors.
Signed-off-by: Rohit Kumar <rohit.kumar3@nutanix.com>
Reviewed-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
DEBUG_IO and DEBUG_RAW_IO are disabled and hence the code #defined under them
are useless. Remove them.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In a few places (e.g. device attach/detach/update) we are given a
device XML, parse it but then need a copy of parsed data so that
the original can be passed to function handling the request over
inactive XML and the copy is then passed to function handling the
operation over live XML. Note, both functions consume passed
device on success, hence the need for copy.
The problem is in combination of how the copy is obtained and
where is passed. The copy is done by calling
virDomainDeviceDefCopy() which does only inactive copy, i.e. no
live information is copied over (e.g. no aliases).
Then, this copy (inactive XML effectively) is passed to function
handling live part of the operation (e.g.
qemuDomainUpdateDeviceLive()) and the definition containing all
the juicy, live bits is passed to function handling inactive part
of the operation (e.g. qemuDomainUpdateDeviceConfig()).
This is rather incorrect, and XML copies should be passed to
their respective functions.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2036895
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
There is no need to do that since both fallible functions do that already.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Callers that already do this anyway can be cleaned up thanks to this and the one
that does not (daemon startup) gains the benefit of the error being printed to
standard error output changing:
LIBVIRT_LOG_OUTPUTS=1:invalid libvirtd
/home/nert/dev/libvirt/upstream/build/src/libvirtd: initialisation failed
into:
LIBVIRT_LOG_OUTPUTS=1:invalid libvirtd
libvirt: error : invalid argument: Invalid destination 'invalid' for output '1:invalid'
/home/nert/dev/libvirt/upstream/build/src/libvirtd: initialisation failed
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@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>
After attesting a domain with the help of domlaunchsecinfo,
domsetlaunchsecstate can be used to set a secret in the guest
domain's memory prior to running the vcpus.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Set a launch secret in guest memory using the sev-inject-launch-secret
QMP API. Only supported with qemu >= 6.0.0 and SEV-enabled guests in a
paused state.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The 'sev-inject-launch-secret' qmp command is only available with
qemu >= 6.0.0. Introduce a capability for sev-inject-launch-secret.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This API allows setting a launch secret within a guests's memory. The
launch secret is created by the guest owner after retrieving and
verifying the launch measurement with virDomainGetLaunchSecurityInfo.
The API uses virTypedParameter for input, allowing it to be expanded
to support other confidential computing technologies. In the case of
SEV, a basic guest launch workflow is described in the SEV API spec
in section "1.3.1 Launch"
https://www.amd.com/system/files/TechDocs/55766_SEV-KM_API_Specification.pdf
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@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>
There are few places in virDomainDefFormatFeatures() which can
use virXMLFormatElement() or virXMLFormatElementEmpty() instead
of writing directly into the output buffer.
After this, there are still a lot of places left, but that is
much bigger task.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
There's no real difference between input and output XMLs for
kvm-features and kvm-features-off test cases. Do what we usually
do in such case - turn the output file into a symlink of the
input file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
We have a subdirectory specifically for CSS files now, so it makes
sense to have the stylesheet that defines fonts to be there too.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This unclutters the top-level docs directory.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This unclutters the top-level docs directory.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
It was introduced in ff4ede0055 but it doesn't seem to have
ever actually been used anywhere.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We no longer need its contents.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We no longer use them anywhere.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
According to ioctl_ficlonerange(2)
These ioctl operations [FICLONE and FICLONERANGE] first
appeared in Linux 4.5. They were previously known as
BTRFS_IOC_CLONE and BTRFS_IOC_CLONE_RANGE, and were private
to Btrfs.
We no longer target any distro that comes with a kernel older
than 4.5, so we can stop looking for the btrfs and xfs
specific versions of the constant and just use the generic
version directly.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The virt_socket_lib is built from virnetsocket.c (among others).
But this file includes virprobe.h which includes libvirt_probes.h
which is a generated file. But this dependency is not recorded in
meson which may lead to a failed build.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The virDomainTPMDefFormat() function can't fail really. There's
no point in it returning an integer then. Make it return void and
fix both places which check for its retval.
And while at it, turn @def into a const pointer to make it
obvious the function does not modify passed struct.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Make the tpm-*.xml files symlinks to their respective input XMLs
from qemuxml2argvdata/ directory. Neither of the XMLs relies on
autofill of any TPM data.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The <tpm/> element formatting is handled in
virDomainTPMDefFormat() which uses the "old style" - appending
strings directly into the output buffer. With this, it's easy to
get conditions that tell when an element has ended wrong. In this
particular case, if both <encryption/> and <active_pcr_banks/>
are to be formatted the current code puts a stray '>' into the
output buffer, resulting in invalid XML.
Rewrite the function to use virXMLFormatElement() which is more
clever.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2016599#c15
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
We already have the input xml because of xml2arg test. However,
the corresponding xml2xml test case is missing. Make the expected
XML a symlink to the input XML and clean the latter up a bit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
