This test shows a bug we have: even though the XML says:
<allocation mode='immediate'/>
there is no -mem-prealloc nor .prealloc=yes anywhere on the cmd
line. This will be fixed in the next commit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In a few cases we call a public API, wrapped in an if() statement
with both branches written out explicitly. The error branch jumps
onto cleanup label, while the successful prints out a message.
Right after these ifs there's 'ret = true;' and the cleanup
label. The code is a bit more readable if only the error branch
is kept and printing happens at the same level as setting the ret
variable.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Kristína Hanicová <khanicov@redhat.com>
Currently, the dommigrate example returns 0 or 1 for success or
failure state, respectively. Except for a few cases where it
forgot to change the @ret variable just before jumping onto the
'cleanup' label. Making the code follow our usual pattern
(initialize @ret to an error value and set it to success value
only at the end) fixes those cases. Also, using EXIT_SUCCESS and
EXIT_FAILURE is more portable (even though on my system they are
just an alias to values the example already uses).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Kristína Hanicová <khanicov@redhat.com>
The usage() function should just print expected arguments. Make
the function return void then.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Kristína Hanicová <khanicov@redhat.com>
Similarly to one of previous commits, there's no need to
increment domain object refcounter before unlocking it. Any
number of lock and unlock calls over domain object has no effect
on the refcounter.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
After previous cleanups this callback is unused. Remove it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently, when opening an agent socket the qemuConnectAgent()
increments domain object refcounter and calls qemuAgentOpen()
where the domain object pointer is simply stored inside
_qemuAgent struct. If qemuAgentOpen() fails, then it clears @cb
member only to avoid qemuProcessHandleAgentDestroy() being called
(which decrements the domain object refcounter) and the domain
object refcounter is then decreased explicitly in
qemuConnectAgent().
The same result can be achieved with much cleaner code: increment
the refcounter inside qemuAgentOpen() and drop the dance around
@cb.
Also, the comment in qemuConnectAgent() about holding an extra
reference is not correct. The thread that called
qemuConnectAgent() already holds a reference to the domain
object. No matter how many time the object is locked and unlocked
the reference counter can't be decreased.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Just like qemuMonitorOpen(), hold the domain object locked
throughout the whole time of qemuConnectAgent() and unlock it
only for a brief time of actual connect() (because this is the
only part that has a potential of blocking).
The reason is that qemuAgentOpen() does access domain object
(well, its privateData) AND also at least one argument (@context)
depends on domain object. Accessing these without the lock is
potentially dangerous.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1845468#c12
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This commit doesn't aim to extinguish every VIR_FREE() call, but
only those which were touched by the previous commit. The aim is
to drop cleanup/error labels.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Instead of calling qemuMonitorTestFree() explicitly, we can use
g_autoptr() and let it be called automagically.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Previous commit rendered 'cleanup' label and @ret variable
redundant. The same result can be achieved by returning 0/-1
directly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
There are two instances of an explicit call to
qemuMonitorCPUModelInfoFree() which in fact can be turned into
g_auto().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
There are a few cases where a string list is freed by an explicit
call of g_strfreev(), but the same result can be achieved by
g_atuo(GStrv).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
There are two functions (testQemuAgentOSInfo() and
testQemuAgentTimezone()) which call virTypedParamsFree() only in
successful paths. If an error is met then those parameters would
be leaked. Fix this by placing the virTypedParamsFree() calls on
better place.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Instead of explicit virObjectUnlock(obj) + virObjectUnref(obj)
combo the virSecretObjEndAPI() can be used.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Instead of explicit virObjectUnlock(obj) + virObjectUnref(obj)
combo the virNodeDeviceObjEndAPI() can be used.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Instead of explicit virObjectUnlock(obj) + virObjectUnref(obj)
combo the virNWFilterBindingObjEndAPI() can be used.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Instead of explicit virObjectUnlock(obj) + virObjectUnref(obj)
combo the virInterfaceObjEndAPI() can be used.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Instead of explicit virObjectUnlock(obj) + virObjectUnref(obj)
combo the virDomainObjEndAPI() can be used.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Some forward declarations in bridge_driver.c are not needed
really. They only create a noise when trying to jump onto the
correct tag. Drop them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@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>
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>
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>
The virCapabilitiesAddGuestDomain() function can't fail. It
aborts on OOM. Therefore, there's no need to check for its
return value.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virCapabilitiesAddGuest() function can't fail. It aborts on
OOM. Therefore, there's no need to check for its return value.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In ch_driver.c there are two forward declarations that are not
needed. Drop them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are two bugs I fixed worth mentioning in the 7.9.0 release
notes.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
It may happen that qemuProcessStop() is called from "qemu-event"
thread. But this thread doesn't have any virIdentity set
(virIdentity being thread local) and therefore it may be unable
to open connection to secondary drivers. It is unable to do so
in split daemon scenario, because in there opening a connection
is coupled with copying current thread identity onto the
connection. Code-wise, virIdentityGetCurrent() returns NULL which
in turn makes virGetConnectGeneric() fail. This problem does not
occur in monolithic daemon scenario, because no identity copying
is done there.
Long story short, inability to open secondary driver connection
can lead to unwanted results. Therefore, do what
qemuProcessReconnectHelper() does - set the new thread identity
to be the one of the caller.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2013573
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In some cases the worker func running inside the pool may rely on
virIdentity. While worker func could check for identity and set
one it is not optimal - it may not have access to the identity of
the thread creating the pool and thus would have to call
virIdentityGetSystem(). Allow passing identity when creating the
pool.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
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>
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>
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>
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>
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>
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>
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>
There's one place (specifically qemuMonitorJSONParseCPUModel())
where we can avoid explicit free call for qemuMonitorCPUModelInfo
struct.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
We have g_autoptr() for virCPUData struct defined already. Let's
use it in qemu_monitor_json.c and drop explicit free calls.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
There are a few files containing expected output for test cases
that no longer exist. Remove them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When a server decides to close a client, the
virNetServerClientCloseLocked() is called. In here various
cleanup steps are taken, but the most important part (from this
commit's POV at least) is the way that the socket is closed.
Firstly, removal of the socket associated with the client from
the event loop is signalized and then the socket is unrefed. The
socket is not closed just yet though, because the event loop
holds a reference to it. This reference will be freed as soon as
the event loop wakes up and starts issuing callbacks (in this
case virNetSocketEventFree()).
So far, this is how things usually work. But if the daemon
reaches the number of opened files limit, things start to work
differently.
If the RLIMIT_NOFILE limit is reached and there's a client that
wants to connect then the event loop wakes up, sees POLLIN on the
socket and calls virNetServerServiceAccept() which in turn calls
virNetSocketAccept(). But because of the limit, accept() fails
with EMFILE leaving the POLLIN event unhandled. The dispatch then
continues to next FDs with events on them. BUT, it will NOT call
the socket removal callback (virNetSocketEventFree()) because it
has low priority (G_PRIORITY_DEFAULT_IDLE). Per glib's
documentation:
* Each event source is assigned a priority. The default priority,
* %G_PRIORITY_DEFAULT, is 0. Values less than 0 denote higher priorities.
* Values greater than 0 denote lower priorities. Events from high priority
* sources are always processed before events from lower priority sources.
and per g_idle_add() documentation:
* Adds a function to be called whenever there are no higher priority
* events pending to the default main loop. The function is given the
* default idle priority, %G_PRIORITY_DEFAULT_IDLE.
Now, because we did not accept() the client we are constantly
seeing POLLIN on the main socket and thus the removal of the
client socket won't ever happen.
The fix is to set at least the same priority as other sources,
but since we want to just close an FD, let's give it the highest
priority and call it before handling other events.
This issue can be easily reproduced, for instance:
# ulimit -S -n 40 (tweak this number if needed)
# ./src/libvirtd
from another terminal:
# for ((i=0; i<100; i++)); do virsh list & done; virsh list
The last `virsh list` must not get stuck.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2007168
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
There are few places where we can replace explicit
VIR_FORCE_CLOSE() with VIR_AUTOCLOSE annotation.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Similarly to virshDomainFree add a wrapper for the snapshot object
freeing function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Similarly to virshDomainFree add a wrapper for the snapshot object
freeing function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Similarly to virshDomainFree add a wrapper for the snapshot object
freeing function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Similarly to virshDomainFree add a wrapper for the snapshot object
freeing function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Similarly to virshDomainFree add a wrapper for the snapshot object
freeing function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Similarly to virshDomainFree add a wrapper for the snapshot object
freeing function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Similarly to virshDomainFree add a wrapper for the snapshot object
freeing function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Currently the order of virshXXXFree functions in the header file
does not correspond to the order in the corresponding .c file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
In case when libvirt runs inside a restricted container it may
not have enough permissions to modify unpriv_sgio. However, it
may have been set beforehand by sysadmin or an orchestration
tool. Therefore, let's check whether the currently set value is
the one we want and if it is refrain from writing to the file.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2010306
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The --nvram and --keep-nvram options of the undefine command can
be used regardless of the domain status (the only consumer so far
- qemuDomainUndefineFlags() doesn't care about the domain
status). Yet, their corresponding help strings say something
about inactive domains while manpage says nothing. Remove the
reference to domain state.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2007659
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This commit adds new memorydevices.rst page which should serve
all models of memory devices. Yet, I'm documenting virtio-mem
quirks only.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
New 'update-memory-device' command is introduced which aims on
making it user friendly to change <memory/> device. So far I just
need to change <requested/> so I'm introducing --requested-size
only; but the idea is that this is extensible for other cases
too. For instance, want to change <myElement/>? A new
--my-element argument can be easily introduced.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The qemuDomainSetMemoryFlags() allows for memballoon
(<currentMemory/>) changes for both active and inactive guests.
And just before doing any change, we have to make sure that the
new size is not greater than the total memory (<memory/>).
However, the total memory includes not only the regular guest
memory, but also sum of maximum sizes of all virtio-mems (in fact
all memory devices for that matter). But virtio-mem devices are
modified differently (via virDomainUpdateDevice()) and thus the
upper limit for new balloon size has to be lowered.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reporting how much memory is exposed to the guest happens under
<currentMemory/> which is taken from def->mem.cur_balloon. The
reported amount should account for both balloon size and the sum
of @currentsize of all virtio-mems. For instance, if domain has
4GiB via balloon and additional 2GiB via virtio-mem, then the
domain XML should report 6GiB. The same applies for domain
statistics.
The way to achieve this is to account for either balloon or
virtio-mem when the size of the other is changed, e.g. on balloon
change we have to add all @currentsize (for non virtio-mem these
will be zero, so the check for memory model is needless, but
makes it more obvious what's happening), and vice versa.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
If the QEMU driver restarts it loses the track of the current size
of virtio-mem (because it's runtime type of information and thus
not stored in XML) and therefore, we have to refresh it when
reconnecting to the domain monitor.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As advertised in previous commit, this event is delivered to us
when virtio-mem module changes the allocation inside the guest.
It comes with one attribute - size - which holds the new size of
the virtio-mem (well, allocated size), in bytes.
Mind you, this is not necessarily the same number as 'requested
size'. It almost certainly will be when sizing the memory up, but
it might not be when sizing the memory down - the guest kernel
might be unable to free some blocks.
This current size is reported in the domain XML as an output
element only.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This function will be needed in the next commit where we will
want to find virtio-mem given its alias by QEMU on the monitor.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virtio-mem has another property that isn't exposed yet:
current size exposed to the guest. Please note, that this is
different to <requested/> because esp. on sizing the memory
down guest may refuse to release some blocks. Therefore, let's
have another size to report in the XML. But because of its
nature, the <current/> won't be parsed and is report only (for
live XMLs).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Updating offline XML of <memory/> devices might come handy when
dealing with virtio-mem devices. But it's implemented to just
replace one virDomainMemoryDef with another so it can be used to
change almost anything.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As advertised in one of previous commits, we want to be able to
change 'requested-size' attribute of virtio-mem on the fly. This
commit does exactly that. Changing anything else is checked for
and forbidden.
Once guest has changed the allocation, QEMU emits an event which
we will use to track the allocation. In the next commit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Nothing special is happening here. All important changes were
done when for 'virtio-pmem' (adjusting the code to put virtio
memory on PCI bus, generating alias using
qemuDomainDeviceAliasIndex(). The only bit that might look
suspicious is no prealloc for virtio-mem. But if you think about
it, the whole purpose of this device is to change amount of
memory exposed to guest on the fly. There is no point in locking
the whole backend in memory.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virtio-mem is paravirtualized mechanism of adding/removing
memory to/from a VM. A virtio-mem-pci device is split into blocks
of equal size which are then exposed (all or only a requested
portion of them) to the guest kernel to use as regular memory.
Therefore, the device has two important attributes:
1) block-size, which defines the size of a block
2) requested-size, which defines how much memory (in bytes)
is the device requested to expose to the guest.
The 'block-size' is configured on command line and immutable
throughout device's lifetime. The 'requested-size' can be set on
the command line too, but also is adjustable via monitor. In
fact, that is how management software places its requests to
change the memory allocation. If it wants to give more memory to
the guest it changes 'requested-size' to a bigger value, and if it
wants to shrink guest memory it changes the 'requested-size' to a
smaller value. Note, value of zero means that guest should
release all memory offered by the device. Of course, guest has to
cooperate. Therefore, there is a third attribute 'size' which is
read only and reflects how much memory the guest still has. This
can be different to 'requested-size', obviously. Because of name
clash, I've named it 'current' and it is dealt with in future
commits (it is a runtime information anyway).
In the backend, memory for virtio-mem is backed by usual objects:
memory-backend-{ram,file,memfd} and their size puts the cap on
the amount of memory that a virtio-mem device can offer to a
guest. But we are already able to express this info using <size/>
under <target/>.
Therefore, we need only two more elements to cover 'block-size'
and 'requested-size' attributes. This is the XML I've came up
with:
<memory model='virtio-mem'>
<source>
<nodemask>1-3</nodemask>
<pagesize unit='KiB'>2048</pagesize>
</source>
<target>
<size unit='KiB'>2097152</size>
<node>0</node>
<block unit='KiB'>2048</block>
<requested unit='KiB'>1048576</requested>
</target>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</memory>
I hope by now it is obvious that:
1) 'requested-size' must be an integer multiple of
'block-size', and
2) virtio-mem-pci device goes onto PCI bus and thus needs PCI
address.
Then there is a limitation that the minimal 'block-size' is
transparent huge page size (I'll leave this without explanation).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This capability tracks whether memory-backend-* supports .reserve
attribute which is going to be important for backends associated
with virtio-mem devices.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This commit introduces a new capability that reflects virtio-mem-pci
device support in QEMU:
QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI, /* -device virtio-mem-pci */
The virtio-mem-pci device was introduced in QEMU 5.1.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
New virHostMemGetTHPSize() is introduced which allows caller to
obtain THP PMD (Page Middle Directory) size, which is equal to
the minimal size that THP can use, taken from kernel doc
(Documentation/admin-guide/mm/transhuge.rst):
Some userspace (such as a test program, or an optimized memory allocation
library) may want to know the size (in bytes) of a transparent hugepage::
cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
Since this size depends on the host architecture and the kernel
it won't change whilst libvirtd is running. Therefore, we can use
virOnce() and cache the value. Of course, we can be running under
kernel that has THP disabled or has no notion of THP at all. In
that case a negative value is returned to signal error.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are two variables that are used only in a single
loop. Move their definitions into their respective blocks.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
When parsing CPU topology, which is described in <topology/>
attributes we can use virXMLPropUInt() instead of virXPathUInt()
as the former results in shorter code.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
There is no need to use virXPathULong() and a temporary UL
variable if we can use virXPathUInt() directly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik