Create a new helper to remove the GIC parse logic from the body of
virQEMUCapsLoadCache().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Create a new helper to remove the parse capabilities flag logic from the
body of virQEMUCapsLoadCache().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
The content of /sys/module/kvm_amd/parameters/sev may vary depending on
the kernel version. Check also for 'Y' and 'y' in addition to '1' to
cover several possible variants. The fix is similar to the one
introduced in commit 3f9c1a4bb841
Signed-off-by: Vasiliy Ulyanov <vulyanov@suse.de>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Originally the default encryption engine is populated in the disk
post-parse callback code. This works for disks but for any additional
images introduced either via the block copy API or via the backup API we
don't populate the default.
In case when the backup or block copy is requested on an encrypted image
this would then lead to an error:
error: internal error: Unexpected enum value 0 for virStorageEncryptionEngine
This patch adds another point where we populate the default which is
when setting up a virStorageSource for actual usage.
We keep the original setting in the post-parse callback as that's the
only point that is recorded in the XML file after definition.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2023674
Fixes: ab1d46d6128
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Before commit 73c352ab8c97d3 which converted the hostdev commandline
formatter to JSON the 'ramfb' property was formatted only if it was
enabled.
The main reason for that is that enabling 'ramfb' switches the device
model to 'vfio-pci-nohotplug' which actually has the property, while
'vfio-pci' (used when 'ramfb' is disabled or absent) doesn't have it.
Restore the logic to format 'ramfb' only when it's enabled and add a
comment that it's deliberate.
Fixes: 73c352ab8c97d3
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2024435
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'virDomainChrSourceDef' contains private data so 'virDomainChrSourceDefNew'
must be used to allocate it. 'virDomainTPMDef' was using it directly
which won't work with the chardev helper functions.
Convert it to a pointer to properly allocate private data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It's referenced only once and it's a shortcut to the chardev source thus
can be used directly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rather than returning a different error code if the device address needs
to be released pass in the 'need_release' flag via a pointer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function is already getting 'virDomainObj' which has already the
driver pointer present.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Switch to automatic memory clearing for the two virJSONValues and remove
the 'cleanup' label and 'ret' variable.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The main reason is to ensure that the private data are properly
allocated for every instance.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function is already returning JSON properties, rename it
accordingly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use 'virReportEnumRangeError' for the invalid cases and keep the
original error for known but unsupported chardevs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the addition of the command wrapper to qemuMonitorJSONAttachCharDev
and rename the function to qemuMonitorJSONAttachCharDevGetProps.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use 'qemuMonitorJSONMakeCommandInternal' instead of
'qemuMonitorJSONMakeCommand' + 'virJSONValueObjectAppend'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a simple wrapper for 'qemuMonitorAttachCharDev' named
'qemuHotplugChardevAttach' which will simplify the moving of the
character device property generator out of the monitor code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'xmlopt' parameter can be auto-unref by using g_autoptr().
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
There is no guarantee that QEMU and libvirt have been configured
with the same prefix.
In particular, Homebrew on macOS will pass a different, private
prefix for each package version and then use symlinks to make
the files for a specific version appear in the usual locations.
This works perfectly fine as long as one package doesn't try to
go poking around another package's data - which is exactly what
libvirt needs to do in order to read and parse the QEMU interop
data.
qemu_datadir can now be explicitly provided to make this and
other uncommon scenarios work. The common scenario, where QEMU
and libvirt both use the same prefix, is unaffected.
https://gitlab.com/libvirt/libvirt/-/issues/168
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use abstract names that more closely match the Meson
nomenclature.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While datadir must live under prefix, there is no requirement
that its name must necessarily be "share": a different,
arbitrary name could have been provided by the user.
Fixes: 3c876d2428ee3abbb11a50698a9e225cffb72cbc
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
'-audiodev' as a modern implementation based on QAPI already takes JSON
as the argument. Convert our code to use it directly.
The declaration of the QAPI types can be found in
'qemu.git/qapi/audio.json'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virJSONValueObjectAdd now works identically to virJSONValueObjectCreate
when used with a NULL argument. Replace all callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virJSONValueObjectAdd now works identically to virJSONValueObjectCreate
when used with a NULL argument. Replace all callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcomming patch will convert virJSONValueObjectCreate which didn't check
the value of the passed argument to virJSONValueObjectAdd which will and
this would lead to crashes.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virJSONValueObjectAdd now works identically to virJSONValueObjectCreate
when used with a NULL argument. Replace all callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virJSONValueObjectAdd now works identically to virJSONValueObjectCreate
when used with a NULL argument. Replace all callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virJSONValueObjectAdd now works identically to virJSONValueObjectCreate
when used with a NULL argument. Replace all callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virJSONValueObjectAdd now works identically to virJSONValueObjectCreate
when used with a NULL argument. Replace all callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virJSONValueObjectAdd now works identically to virJSONValueObjectCreate
when used with a NULL argument. Replace all callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Pass in the double pointer from the wrappers directly to
virJSONValueObjectAddVArgs, which will allow us to directly allocate the
new objects inside the function.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Change the first argument to a double pointer so that later the function
can be unified with virJSONValueObjectCreate and fix all callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The upcoming QEMU 6.2.0 implements a new event called
DEVICE_UNPLUG_GUEST_ERROR, a new event that reports generic device
unplug errors that were detected by the guest and reported back to QEMU.
This new event is going to be specially useful for pseries guests that
uses newer kernels (must have kernel commit 29c9a2699e71), which is the
case for Fedora 34 at this moment. These guests have the capability of
reporting CPU removal errors back to QEMU which, starting in 6.2.0, will
emit the DEVICE_UNPLUG_GUEST_ERROR event. Libvirt can use this event to
abort the device removal immediately instead of waiting for 'setvcpus'
timeout.
QEMU 6.2.0 is also going to emit DEVICE_UNPLUG_GUEST_ERROR for memory
hotunplug errors, both in pseries and ACPI guests. QEMU 6.1.0 reports
memory removal errors using the MEM_UNPLUG_ERROR event, which is going to
be deprecated by DEVICE_UNPLUG_GUEST_ERROR in 6.2.0. Given that
Libvirt wasn't handling the MEM_UNPLUG_ERROR event we don't need to
worry about it - adding support to DEVICE_UNPLUG_GUEST_ERROR will be
enough to cover all future cases.
This patch adds support to DEVICE_UNPLUG_GUEST_ERROR by adding the
minimal wiring required for Libvirt to be aware of it. The monitor
callback for this event will abort the pending removal operation of the
device reported by the "device" property of the event. Most of the heavy
lifting is already done by existing code that handles
QEMU_DOMAIN_UNPLUGGING_DEVICE_STATUS_GUEST_REJECTED, making our life
easier to abort the pending removal operation.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.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>
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>
During the vm rebooting, the vm could be paused if the libvirtd is
restarted for some reason, which is not expected. We need continue
fakereboot process if fakereboot flags is true and the vm is in
paused-user status.
Signed-off-by: Bihong Yu <yubihong@huawei.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
During the vm rebooting, the vm could be shut down if the libvirtd is
restarted for some reason, which is not expected. We move set
fakereboot flags false after processing fakereboot over, so we can
ensure that fakereboot process have been executed.
Signed-off-by: Bihong Yu <yubihong@huawei.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This patch improves readability of the function and makes the
code look cleaner by removing the 'else' branches after return
and reordering of the 'if' branches.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Commit 88957116c9d3cb4705380c3702c9d4315fb500bb switched to use
memory-backend-* for regular VM memory as well. That change indirectly
started using 'host-nodes' for system memory which results in QEMU
calling mbind() to bind the system memory to specific NUMA node if the
VM XML contains the configuration similar to this:
...
<numatune>
<memory mode='strict' nodeset='0'/>
</numatune>
...
Once the VM was started with that configuration it was no longer
possible to change the memory NUMA nodeset.
Fixes: 677c90cc1d1fcb3aba09b5d4f0f8f83099911775
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
