Michal Privoznik [Mon, 25 Oct 2021 13:14:51 +0000 (15:14 +0200)]
qemuProcessHandleMemoryDeviceSizeChange: Use qemuProcessEventSubmit()
This is a typical example of what can go wrong when sending out
an old patch. Back in January, when I was writing
qemuProcessHandleMemoryDeviceSizeChange() events were sent to the
worker pool thread using virThreadPoolSendJob(). Then, in July a
helper was introduced (qemuProcessEventSubmit()) but since my
code was not committed and I did not pay attention my code wasn't
updated. Later, when I merged my code it uses the old approach.
BTW: this also fixes a possible double free which I completely
missed when writing the code ~10 months ago.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Mon, 25 Oct 2021 13:15:09 +0000 (15:15 +0200)]
qemu_monitor: Make domainMemoryDeviceSizeChange cb return void
Nobody's interested in the return value of any of
struct _qemuMonitorCallbacks callbacks. They are all void, but
domainMemoryDeviceSizeChange. Change it to void.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Jiri Denemark [Mon, 25 Oct 2021 14:30:41 +0000 (16:30 +0200)]
storage_file: Compute QCOW2 cluster size as ULL
While the QCOW2 cluster size is represented in only 4 bits in the QCOW2
header and thus 1 << cluster_size cannot overflow int,
qcow2GetClusterSize is supposed to return unsigned long long so we can
just compute the result as ULL rather than computing it as int and
promoting to unsigned long long.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Ani Sinha [Sun, 24 Oct 2021 05:40:43 +0000 (11:10 +0530)]
qemu: remove unused function return value
qemuBuildPMPCIRootHotplugCommandLine() returns 0 unconditionally. There is no
failure scenario at present. So clean up the code by removing integer return
from the function and also remove the failure check conditional from the
function call.
Also fix indentation for the above function call while at it.
Signed-off-by: Ani Sinha <ani@anisinha.ca> Reviewed-by: Laine Stump <laine@redhat.com>
Ani Sinha [Thu, 21 Oct 2021 03:30:26 +0000 (09:00 +0530)]
qemu: Fix hotplug error message format to conform to spec
Error messages must conform to spec as specified here:
https://www.libvirt.org/coding-style.html#error-message-format
This change makes some error messages conform to the spec above.
Fixes: 8eadf82fb5 ("conf: introduce option to enable/disable pci hotplug on pci-root controller") Signed-off-by: Ani Sinha <ani@anisinha.ca> Reviewed-by: Laine Stump <laine@redhat.com>
* this file had been renamed from its original, then renamed back,
which understandably confused git. It's being completely removed
here anyway, so the contents don't matter.
tests/qemuxml2argvtest.c
* change in context around removed chunk
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Ani Sinha <ani@anisinha.ca>
the test output of these files was regenerated because the tests
were changed upstream to use JSON on the commandline at a later
commit than the commit being reverted here (where they were changed
to use latest caps, but the patches to use JSON on the commandline
hadn't been committed yet).
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Ani Sinha <ani@anisinha.ca>
These files are unrelated to the functionality we need to remove, so
they weren't removed, and the associated test cases weren't removed
from qemuxml2argvtest.c
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Ani Sinha <ani@anisinha.ca>
This is the first in a series of 10 commits that revert (in reverse
order) the changes to add the <acpi-hotplug-bridge state='on|off'/>
switch to libvirt domain XML, which unfortunately needs to be removed
due to QEMU developers discovering a flaw with the design of the QEMU
commandline switch used to implement the libvirt switch that will
likely result in a new and different method of selecting hotplug
modes. Because the libvirt switch has not been in any official
releases of libvirt, we are still able to remove it completely, rather
than deprecating it.
The meson 0.60.0 release introduced a bug with the '/' operator when
using an empty path component. '/foo' / '' will now result in '/foo'
not '/foo/'
https://github.com/mesonbuild/meson/issues/9450
This breaks libvirt because xsltproc requires the trailing '/' on the
output directory path. Fortunately the explicit 'join_paths' function
is not affected by the regression
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Or Ozeri [Sun, 24 Oct 2021 09:51:30 +0000 (04:51 -0500)]
conf: add luks2 encryption format
This commit extends libvirt XML configuration to support luks2 encryption format.
This means that <encryption format="luks2" engine="librbd"> becomes valid.
Currently librbd is the only engine that supports this new format.
Signed-off-by: Or Ozeri <oro@il.ibm.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Or Ozeri [Sun, 24 Oct 2021 09:51:28 +0000 (04:51 -0500)]
conf: add encryption engine property
This commit extends libvirt XML configuration to support a custom encryption engine.
This means that <encryption format="luks" engine="qemu"> becomes valid.
The only engine for now is qemu. However, a new engine (librbd) will be added in an upcoming commit.
If no engine is specified, qemu will be used (assuming qemu driver is used).
Signed-off-by: Or Ozeri <oro@il.ibm.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Or Ozeri [Sun, 24 Oct 2021 09:51:26 +0000 (04:51 -0500)]
qemu: add disk post parse to qemublocktest
The post parse callback is part of the real (non-test) processing flow.
This commit adds it (for disks) to the qemublocktest flow as well.
Specifically, this will be needed for tests that use luks encryption,
so that the default encryption engine (which is added in an upcoming commit)
will be overridden by qemu.
Signed-off-by: Or Ozeri <oro@il.ibm.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Fri, 22 Oct 2021 07:59:51 +0000 (09:59 +0200)]
qemu_monitor_json: Drop pointless error labels
After previous cleanups, some 'error' labels were rendered
needless - they contain nothing more than a return statement.
Well, those labels can be dropped and 'goto error' can be
replaced with return statement directly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Michal Privoznik [Thu, 21 Oct 2021 08:33:51 +0000 (10:33 +0200)]
qemu_monitor_json: Drop pointless cleanup labels
After previous cleanups, some 'cleanup' labels were rendered
needless - they contain nothing more than a return statement.
Well, those labels can be dropped and 'goto cleanup' can be
replaced with return statement directly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Michal Privoznik [Thu, 21 Oct 2021 08:21:24 +0000 (10:21 +0200)]
qemu_monitor_json: Use g_autofree
Let's replace VIR_FREE() calls with g_autofree. Not all calls can
be replaced though - the legitimate ones are kept (e.g. those
which free array, or which free a struct for which we don't have
g_autoptr() yet, and so on).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Michal Privoznik [Thu, 21 Oct 2021 08:14:47 +0000 (10:14 +0200)]
qemu_monitor_json: Use g_autoptr() for virJSONValue
A lot of explicit free calls can be saved when virJSONValue
variables are declared with g_autoptr(). There's one caveat:
there was a slight deviation from our usual pattern such that
@cmd variable was not initialized to NULL but as the very first
step it was assigned a value using qemuMonitorJSONMakeCommand().
While this works in theory it upset my GCC-11.2 (but only when
building with -O2). So I had to initialize the variable in such
case too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Michal Privoznik [Fri, 22 Oct 2021 05:44:03 +0000 (07:44 +0200)]
qemuMonitorJSONExtractPRManagerInfo: Declare @entry inside the loop
The reason why @entry variable in qemuMonitorJSONExtractPRManagerInfo()
was declared at the top most level was that the variable is used under
the cleanup label. However, if declared using g_autofree then the
variable can be declared inside the loop it is used in.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Michal Privoznik [Fri, 22 Oct 2021 05:17:03 +0000 (07:17 +0200)]
qemuMonitorJSONQueryRxFilterParse: Set *filter only on success
The qemuMonitorJSONQueryRxFilterParse() function is called to
parse the output of 'query-rx-filter' and store results into
passed virNetDevRxFilter structure. However, it is doing so in a
bit clumsy way - the return pointer is set in all cases (i.e.
even in case of error) and thus the cleanup label is more
complicated than it needs to be. With a help of g_autoptr() and
g_steal_pointer() the return pointer can be set only in case of
success - which is what callers expect anyway.
The same applies to qemuMonitorJSONQueryRxFilter().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Michal Privoznik [Fri, 22 Oct 2021 05:07:09 +0000 (07:07 +0200)]
qemuMonitorJSONGetMigrationStats: Don't clear @stats on failure
In the qemuMonitorJSONGetMigrationStats() there's a code under
cleanup label that's clearing returned @stats if the function
returns with an error. However, transitively there's just one
caller - qemuMigrationAnyFetchStats() - and it doesn't care for
this behaviour. Drop the code to simplify the cleanup label.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Michal Privoznik [Fri, 22 Oct 2021 08:08:35 +0000 (10:08 +0200)]
qemuMonitorJSONHumanCommand: Require @reply_str
All callers of qemuMonitorJSONHumanCommand() pass a non-NULL pointer
as @reply_str therefore there's no need to check whether it is NULL.
NB, the sister function (qemuMonitorJSONArbitraryCommand()) doesn't
check for NULL either.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Michal Privoznik [Thu, 21 Oct 2021 10:53:35 +0000 (12:53 +0200)]
qemu_monitor_json: Don't transfer ownership to @msg
In qemuMonitorJSONCommandWithFd() given command (represented by
virJSONValue struct) is translated to string (represented by
virBuffer). The ownership of the string is then transferred to
the message which is then sent. The downside of this approach is
we have to have an explicit call to free the string from the
message. But if the message just "borrowed" the string (which it
can safely do because it is just reading from the string) then
automatic free of the buffer takes care of freeing the string.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Michal Privoznik [Thu, 21 Oct 2021 10:52:14 +0000 (12:52 +0200)]
qemu_monitor_json: Don't check for qemuMonitorNextCommandID() retval
The qemuMonitorNextCommandID() function can never fail. There's
no need to check for its retval then. Moreover, the temporary
variable used to hold the retval can be declared in the inner
most block.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Michal Privoznik [Fri, 22 Oct 2021 08:56:01 +0000 (10:56 +0200)]
lib: Drop intermediary return variables
In a few places we declare a variable (which is optionally
followed by a code not touching it) then set the variable to a
value and return the variable immediately. It's obvious that the
variable is needless and the value can be returned directly
instead.
This patch was generated using this semantic patch:
@@
type T;
identifier ret;
expression E;
@@
- T ret;
... when != ret
when strict
- ret = E;
- return ret;
+ return E;
After that I fixed couple of formatting issues because coccinelle
formatted some lines differently than our coding style.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 20 Oct 2021 07:03:04 +0000 (09:03 +0200)]
qemuMonitorJSONGetMigrationCapabilities: Don't return early on CommandNotFound
The qemuMonitorJSONGetMigrationCapabilities() command executes
'query-migrate-capabilities' command and returns early if QEMU
doesn't know the command. Well, the command was introduced in
QEMU release 1.2 (specifically in commit v1.2.0-rc0~29^2~11) and
since the minimum required version is 2.11.0 we can be sure that
command will always exist.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Thu, 21 Oct 2021 08:50:09 +0000 (10:50 +0200)]
qemuMonitorJSONGetMemoryDeviceInfo: Don't return early on CommandNotFound
The qemuMonitorJSONGetMemoryDeviceInfo() command executes
'query-memory-devices' command and returns early if QEMU
doesn't know the command. Well, the command was introduced in
QEMU release 2.1 (specifically in commit v2.1.0-rc0~41^2~9) and
since the minimum required version is 2.11.0 we can be sure that
command will always exist.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Thu, 21 Oct 2021 08:46:09 +0000 (10:46 +0200)]
qemuMonitorJSONGetKVMState: Don't return early on CommandNotFound
The qemuMonitorJSONGetKVMState() command executes 'query-kvm'
command and returns early if QEMU doesn't know the command. Well,
the command was introduced in QEMU release 0.14 and since the
minimum required version is 2.11.0 we can be sure that command
will always exist.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Thu, 21 Oct 2021 08:42:20 +0000 (10:42 +0200)]
qemuMonitorJSONGetDumpGuestMemoryCapability: Don't return early on CommandNotFound
The qemuMonitorJSONGetDumpGuestMemoryCapability() command
executes 'query-dump-guest-memory-capability' command and returns
early if QEMU doesn't know the command. Well, the command was
introduced in QEMU release 2.0 (specifically in commit
v2.0.0-rc0~43^2~16) and since the minimum required version is
2.11.0 we can be sure that command will always exist.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Thu, 21 Oct 2021 08:37:17 +0000 (10:37 +0200)]
qemuMonitorJSONGetMigrationParams: Don't return early on CommandNotFound
The qemuMonitorJSONGetMigrationParams() function executes
'query-migrate-parameters' command and returns early if QEMU
doesn't know the command. Well, the command was introduced in
QEMU release 2.4 (specifically in commit v2.4.0-rc0~147^2~3) and
since the minimum required version is 2.11.0 we can be sure that
the command will always exist.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Thu, 21 Oct 2021 09:01:03 +0000 (11:01 +0200)]
qemumigparamstest: Drop "unsupported" test case
The aim of "unsupported" test case is to check whether our code
handles 'CommandNotFound' error returned for
'query-migrate-parameters' monitor command. Well, the command is
pretty old and every QEMU that we are dealing with supports it.
Thus this test case is useless. Drop it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
* XML serialization and deserialization of PCI VPD;
* PCI VPD capability flags added and used in relevant places;
* XML to XML tests for the added capability.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
Add support for deserializing the binary PCI/PCIe VPD format and storing
results in memory.
The VPD format is specified in "I.3. VPD Definitions" in PCI specs
(2.2+) and "6.28.1 VPD Format" PCIe 4.0. As section 6.28 in PCIe 4.0
notes, the PCI Local Bus and PCIe VPD formats are binary compatible
and PCIe 4.0 merely started incorporating what was already present in
PCI specs.
Linux kernel exposes a binary blob in the VPD format via sysfs since
v2.6.26 (commit 94e6108803469a37ee1e3c92dafdd1d59298602f) which requires
a parser to interpret.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
Michal Privoznik [Tue, 12 Oct 2021 07:55:38 +0000 (09:55 +0200)]
rpc: Temporarily stop accept()-ing new clients on EMFILE
This commit is related to 5de203f879 which I pushed a few days
ago. While that commit prioritized closing clients socket over
the rest of I/O process, this one goes one step further and
temporarily suspends processing new connection requests.
A brief recapitulation of the problem:
1) assume that libvirt is at the top of RLIMIT_NOFILE (that is no
new FDs can be opened).
2) we have a client trying to connect to a UNIX/TCP socket
Because of 2) our event loop sees POLLIN on the socket and thus
calls virNetServerServiceAccept(). But since no new FDs can be
opened (because of 1)) the request is not handled and we will get
the same event on next iteration. The poll() will exit
immediately because there is an event on the socket. Thus we end
up in an endless loop.
To break the loop and stop burning CPU cycles we can stop
listening for events on the socket and set up a timer tho enable
listening again after some time (I chose 5 seconds because of no
obvious reason).
There's another area where we play with temporarily suspending
accept() of new clients - when a client disconnects and we check
max_clients against number of current clients. Problem here is
that max_clients can be orders of magnitude larger than
RLIMIT_NOFILE but more importantly, what this code considers
client disconnect is not equal to closing client's FD.
A client disconnecting means that the corresponding client
structure is removed from the internal list of clients. Closing
of the client's FD is done from event loop - asynchronously.
To avoid this part stepping on the toes of my fix, let's make the
code NOP if socket timer (as described above) is active.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The repo-lockdown service used to run as a bot outside GitHub, but has
now switched to using the GitHub Actions workflow framework. This
requires use of a new configuration file.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
qemu: remove use of implicit boolean syntax for guest features
Some guest features that map to the -cpu arg are still added using
implicit syntax "feature" which is a deprecated shorthand for
"feature=on".
Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
With the previous refactorings, there's no real benefit from the
qemuBuildCpuFeature helper method. Only one of the callers really
needs the CPU feature name re-writing logic, the others can just
use the right name directly.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
target-i386: Register aliases for feature names with underscores
Libvirt names use underscores so we conditionally tranlate the
names when talking to new QEMU. Since the min QEMU was raised to
version 2.11.0, all QEMU versions we talk to expect hypens, so
the translation can be done unconditionally.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
target-i386: Register aliases for feature names with underscores
Libvirt names use underscores so we conditionally tranlate the
names when talking to new QEMU. Since the min QEMU was raised to
version 2.11.0, all QEMU versions we talk to expect hypens, so
the translation can be done unconditionally.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
ci: switch all non-released distros to be non-gating
The non-released distros have reasonably frequent package installation
failures that can last for days at a time. This makes them unsuitable
for use as gating CI jobs.
This ensures all of the jobs in Debian Sid, Fedora Rawhide, openSUSE
Tumbleweed and FreeBSD Current are marked "allow-failure: true".
This means the jobs still run, but any failure will not be considered
fatal to the pipeline.
Reviewed-by: Ján Tomko <jtomko@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Always fetch the stats for all backing chain members. Callers from
qemu_driver.c already always passed 'true' and the caller from the
migration code won't mind when we fetch all stats.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 19 Oct 2021 13:12:36 +0000 (15:12 +0200)]
qemuDomainGetStatsBlock: Always fetch stats for the full backing chain
Similarly to the fix to 'qemuDomainBlocksStatsGather' we should be
always fetching the full backing chain so that we can avoid any
automatic filter notes which would prevent us from fetching the stats
for the correct nodename.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 19 Oct 2021 12:32:09 +0000 (14:32 +0200)]
qemuDomainBlocksStatsGather: Always fetch stats for the full backing chain
In certain cases such as when running a backup blockjob qemu installs a
filter node between the frontend and the top node of the backend of the
disk. The stats gathering code didn't instruct the monitor code to fetch
the stats for all the layers, so since the top layer now doesn't have
stats we were reporting wrong stats such as allocation.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2015281 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Berger [Tue, 19 Oct 2021 13:43:20 +0000 (09:43 -0400)]
qemu: tpm: Run swtpm_setup --create-config-files in session mode
Using swtpm v0.7.0 we can run swtpm_setup to create default config files
for swtpm_setup and swtpm-localca in session mode. Now a user can start
a VM with an attached TPM without having to run this program on the
command line before. This program needs to run once.
This patch addresses the issue raised in
https://bugzilla.redhat.com/show_bug.cgi?id=2010649
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Peng Liang [Mon, 18 Oct 2021 09:20:12 +0000 (17:20 +0800)]
qemu: Move pid file of virtiofsd to stateDir
Libvirt will put the pid file of virtiofsd to per-domain directory.
However, the ownership of the per-domain directory is the user to run
the QEMU process and the user has the write permission of the directory.
If VM escape occurs, the attacker can
1. write arbitrary content to the pid file (if running QEMU using root),
then the attacker can kill any process by writing appropriate pid to
the pid file;
2. spoof the pid file (if running QEMU using a regular user), then the
virtiofsd process will never be cleared even if the VM is destroyed.
So, move the pid file of virtiofsd from per-domain directory to
stateDir.
Signed-off-by: Peng Liang <liangpeng10@huawei.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peng Liang [Mon, 18 Oct 2021 09:20:11 +0000 (17:20 +0800)]
qemu: Move pid file of pr-helper to stateDir
Libvirt will put the pid file of pr-helper to per-domain directory.
However, the ownership of the per-domain directory is the user to run
the QEMU process and the user has the write permission of the directory.
If VM escape occurs, the attacker can
1. write arbitrary content to the pid file (if running QEMU using root),
then the attacker can kill any process by writing appropriate pid to
the pid file;
2. spoof the pid file (if running QEMU using a regular user), then the
pr-helper process will never be cleared even if the VM is destroyed.
So, move the pid file of pr-helper from per-domain directory to
stateDir.
Signed-off-by: Peng Liang <liangpeng10@huawei.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Mon, 18 Oct 2021 07:54:08 +0000 (09:54 +0200)]
virNodeDeviceDefParse: Don't call post-parse callbacks with NULL def
When parsing of the node device XML fails we'd still call the post-parse
and validation callbacks which makes no sense. Additionally the
callbacks were expecting a non-NULL pointer which leads to a crash.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2014139 Fixes: d5ae634ba28 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
Peter Krempa [Thu, 12 Dec 2019 11:13:21 +0000 (12:13 +0100)]
virsh: Add QMP command wrapping for 'qemu-monitor-command'
Issuing simple QMP commands is pain as they need to be wrapped by the
JSON wrapper:
{ "execute": "COMMAND" }
and optionally also:
{ "execute": "COMMAND", "arguments":...}
For simple commands without arguments we can add syntax sugar to virsh
which allows simple usage of QMP and additionally prepares also for
passing through of the 'arguments' section:
Peter Krempa [Mon, 18 Oct 2021 07:29:38 +0000 (09:29 +0200)]
NEWS: Mention conversion of '-device' to JSON starting with QEMU-6.2
Normally this would be considered an internal detail which we don't
document in the news, but in this case I'd like to make people aware of
the change so that they preferrably report them ASAP.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Fri, 15 Oct 2021 10:21:06 +0000 (12:21 +0200)]
testCompareXMLToArgvValidateSchemaCommand: Add validation for '-device'
Now that we use JSON with -device we can validate it at least partially
(since the schema for 'device_add' is for now incomplete) against the
QMP schema.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Fri, 15 Oct 2021 09:42:19 +0000 (11:42 +0200)]
qemu: Use JSON directly for '-device'
Starting with QEMU-6.2 started accepting a JSON object as argument for
'-device' which will also become the only syntax considered stable by
qemu in the future.
Since libvirt was recently converted to generate the properties via JSON
to begin wit we can start using it on the commandline as well, by simply
enabling the QEMU_CAPS_DEVICE_JSON capability, which we do by probing
for the 'json-cli' feature flag of 'device_add'.
Normally a change which changes a commandline output should be happening
only after the impacted real-caps test files are forked in the version
preceding the change, but in this case it's not necessary as the logic
for generating the device properties stays identical and we just change
the output format (avoid conversion). Additionally we still have a lot
of tests validating the conversion to the old commandline options.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Fri, 15 Oct 2021 10:06:14 +0000 (12:06 +0200)]
testQEMUSchemaValidateCommand: Add possibility for partial QMP validation
The QMP schema for 'device_add' is not complete yet. Allow validation of
incomplete schema so that we can enable at least some validation. Once
there's more schema in the future all present members are still
validated.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Mon, 18 Oct 2021 08:52:47 +0000 (10:52 +0200)]
qemu: Decrease scope of variables in qemuConnectGetAllDomainStats()
There are two variables (@vm and @domflags) in qemuConnectGetAllDomainStats()
that are used only within the for() loop but declared for entire function.
Bring them into the loop to make it obvious they are not used outside of it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
Our general pattern is to initialize @ret to -1 and set it to 0
only at the end of a function. Some functions in
objecteventtest.c do not follow this pattern.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
objecteventtest: Drop lifecycleEventCounter_reset()
The sole purpose of the lifecycleEventCounter_reset() function is
to zero out given lifecycleEventCounter struct. Well, we can let
the compiler zero it out when declaring a variable and just
remove the function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
Jim Fehlig [Wed, 6 Oct 2021 04:23:51 +0000 (22:23 -0600)]
qemu: Do not report eof when processing monitor IO
There have been countless reports from users concerned about the following
error reported by libvirtd when qemu domains are shutdown
internal error: End of file from qemu monitor
While the error is harmless, users often mistaken it for real problem with
their deployments. EOF from the monitor can't be entirely ignored since
other threads may be using the monitor and must be able to detect the EOF
condition.
One potential fix is to delay reporting EOF until the monitor is used
after EOF is detected. This patch adds a 'goteof' member to the
qemuMonitor structure, which is set when EOF is detected on the monitor
socket. If another thread later tries to send data on the monitor, the
EOF error is reported.
Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Fri, 15 Oct 2021 11:41:12 +0000 (13:41 +0200)]
virnetsocket: Use g_auto* more
There are few functions in virnetsocket.c where an object/memory
is freed by explicit call. Use g_autoptr()/g_autofree/VIR_AUTOCLOSE
to do that automatically.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Fri, 15 Oct 2021 11:39:36 +0000 (13:39 +0200)]
virnetsocket: Don't free virCommand in virNetSocketNewConnectCommand()
The aim of virNetSocketNewConnectCommand() is to execute passed
command and attach socket pair/pipe to it so that client socket
can be opened (this is used for connections with alternative
transports, e.g. ssh). The virCommand is created in a caller and
then passed to virNetSocketNewConnectCommand() where it is freed
using virCommandFree(). This approach is wrong on two levels:
1) The deallocation happens on a different level than allocation,
2) There's a WIN32 stub that just reports an error and doesn't
free the command.
However, with g_autoptr() trickery the command can be freed in
caller.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Hiroki Narukawa [Fri, 15 Oct 2021 10:11:49 +0000 (19:11 +0900)]
qemu_validate: Fix capability check for disk queue_size
Commit ad209e7d adds QEMU_CAPS_VIRTIO_BLK_QUEUE_SIZE capability, but
the following commit 2d6d67e1 missed to use it and uses
QEMU_CAPS_VIRTIO_BLK_NUM_QUEUES instead.
This commit fixes the mistake.
Signed-off-by: Hiroki Narukawa <hnarukaw@yahoo-corp.jp> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The capability reflects whether QEMU is capable of -device
virtio-*,ats=. Since the property was introduced in QEMU commit
v2.9.0-rc0~162^2~32 we can safely assume the property is always
present as the minimal version required is 2.11.0.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Fri, 15 Oct 2021 08:56:34 +0000 (10:56 +0200)]
qemuxml2argvtest: Drop negative virtio-*-ats tests
There are some tests cases in qemuxml2argvtest that aim to check
whether our validator rejects <driver ats=''/> when
QEMU_CAPS_VIRTIO_PCI_ATS capability is not present. Well, such
scenario can't happen really because the capability will always
be present.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The capability reflects whether QEMU is capable of -device
virtio-*,iommu_platform=. Since the property was introduced in
QEMU commit v2.9.0-rc0~162^2~37 we can safely assume the property
is always present as the minimal version required is 2.11.0.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Fri, 15 Oct 2021 08:55:49 +0000 (10:55 +0200)]
qemuxml2argvtest: Drop negative virtio-*-iommu tests
There are some tests cases in qemuxml2argvtest that aim to check
whether our validator rejects <driver iommu=''/> when
QEMU_CAPS_VIRTIO_PCI_IOMMU_PLATFORM capability is not present.
Well, such scenario can't happen really because the capability
will always be present.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
projects / thirdparty / libvirt.git / log
