This makes it also work during attach. Also add a test for attaching a
watchdog with incompatible action.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2187278
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The loop initially skipped the first one because it was mainly checking
the incompatible actions, but was then modified to also check the
duplicity of iTCO watchdogs.
While at it change the type of the iteration variable to the usual size_t.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2187133
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We can launch qemu with it, but it will not work since it's not even
probed by the kernel at the mapped address with different machine types
since they are expected to be connected to ISA and not even its newer
LPC counterpart found on q35. And it does not exist on non-x86
architectures.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When starting QEMU, or when hotplugging a PCI device QEMU might
lock some memory. How much? Well, that's an undecidable problem.
But despite that, we try to guess. And it more or less works,
until there's a counter example. This time, it's a guest with
both <hostdev/> and an NVMe <disk/>. I've started a simple guest
with 4GiB of memory:
# virsh dominfo fedora
Max memory: 4194304 KiB
Used memory: 4194304 KiB
And here are the amounts of memory that QEMU tried to lock,
obtained via:
grep VmLck /proc/$(pgrep qemu-kvm)/status
1) with just one <hostdev/>
VmLck: 4194308 kB
2) with just one NVMe <disk/>
VmLck: 4328544 kB
3) with one <hostdev/> and one NVMe <disk/>
VmLck: 8522852 kB
Now, what's surprising is case 2) where the locked memory exceeds
the VM memory. It almost resembles VDPA. Therefore, treat is as
such.
Unfortunately, I don't have a box with two or more spare NVMe-s
so I can't tell for sure. But setting limit too tight means QEMU
refuses to start.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2014030
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
It's quite difficult, if not impossible, to create a working RISC-V VMs
using the current default machine type of 'spike_v1.10'. Change the
default to the more appropriate and virtualization friendly 'virt'
machine type.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
It's quite difficult, if not impossible, to create a usable ARM VMs
using the current default machine type of 'integratorcp'. Change the
default to the more appropriate and virtualization friendly 'virt'
machine type.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
I've tried, then I've tried even harder, but still wasn't able to
make sense of our console backcompat code in all its fine
details. Since I value my sanity, let's just forbid hotunplug of
<console/>, especially since detaching of corresponding <serial/>
works.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When cleaning up after removed device, qemuDomainChrRemove() is
called. But this may fail, in which case we successfully ignore
the failure and virDomainChrDefFree() the device anyway. While it
decreases our memory consumption, it's a bit too far, especially
if the next step is 'virsh dumpxml'. Then our memory consumption
decreases all the way down to zero as we crash.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For a running guest, a <serial/> device can be hotunplugged. This
will then remove also aliased <console/>. Trying to hotplug a
<console/> device then, libvirtd crashed because it dereferences
def->consoles while there's none.
Fixes: 42d53ac799a1d7f1414737caa4deb73871876992
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When removing the compat console from domain defintion, removing
it from the vmdef->consoles array is good, but not sufficient.
The console definition might have been fully allocated (after
daemon restarted and reloaded the status XML). Use
virDomainChrDefFree() to free also the definition.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When hotpluging a <serial/> device, we might need to add a
<console/> device with it (because of some crazy backcompat).
Now, hotplugging is done in several phases. In one of them,
qemuDomainChrPreInsert() allocates space for both devices, and
then qemuDomainChrInsertPreAlloced() actually inserts the device
into domain definition and sets up the <console/> device with it.
Except, the condition that checks whether to create the aliased
<console/> is wrong as it compares nconsoles against 0.
Surprisingly, qemuDomainChrInsertPreAllocCleanup() doesn't suffer
from the same error.
Fixes: daf51be5f1b0f7b41c0813d43d6b66edfbe4f6d9
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
igb is a new network device which will be introduced with QEMU 8.0.0.
It is a successor of e1000e so it has PCIe interface and is understands
virtio-net headers as e1000e does.
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
During qemu driver shutdown, objects are freed in qemuStateCleanup that
could still be used by active worker threads, resulting in crashes. E.g.
a worker thread could be processing a monitor EOF event after the
security manager is already disposed
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fd9a9a1e1fe in virSecurityManagerMoveImageMetadata (mgr=0x7fd948012160, pid=-1, src=src@entry=0x7fd98c072c90, dst=dst@entry=0x0)
at ../../src/security/security_manager.c:468
#1 0x00007fd9646ff0f0 in qemuSecurityMoveImageMetadata (driver=driver@entry=0x7fd948043830, vm=vm@entry=0x7fd98c066db0, src=src@entry=0x7fd98c072c90,
dst=dst@entry=0x0) at ../../src/qemu/qemu_security.c:182
#2 0x00007fd96462c7b0 in qemuBlockRemoveImageMetadata (driver=driver@entry=0x7fd948043830, vm=vm@entry=0x7fd98c066db0, diskTarget=0x7fd98c072530 "vda",
src=<optimized out>) at ../../src/qemu/qemu_block.c:2628
#3 0x00007fd9646929d6 in qemuProcessStop (driver=driver@entry=0x7fd948043830, vm=vm@entry=0x7fd98c066db0, reason=reason@entry=VIR_DOMAIN_SHUTOFF_SHUTDOWN,
asyncJob=asyncJob@entry=QEMU_ASYNC_JOB_NONE, flags=<optimized out>) at ../../src/qemu/qemu_process.c:7585
#4 0x00007fd9646fc842 in processMonitorEOFEvent (vm=0x7fd98c066db0, driver=0x7fd948043830) at ../../src/qemu/qemu_driver.c:4794
#5 qemuProcessEventHandler (data=0x561a93febb60, opaque=0x7fd948043830) at ../../src/qemu/qemu_driver.c:4900
#6 0x00007fd9a9971a31 in virThreadPoolWorker (opaque=opaque@entry=0x561a93fb58e0) at ../../src/util/virthreadpool.c:163
(gdb) p mgr->drv
$2 = (virSecurityDriverPtr) 0x0
Prior to commit 7cf76d4e3ab, the worker thread pool was freed before
disposing any driver objects. Let's return to that pattern, but leave
the other changes made by 7cf76d4e3ab.
Signed-off-by: Tamara Schmitz <tamara.schmitz@suse.com>
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Historically the snapshot code attempted to forbid internal snapshots
with UEFI both in active and inactive case. Unfortunately due to the
intricacies of UEFI probing this didn't really work for inactive VMs
which made users rely on the feature.
Now with the changes to store detected UEFI environment also in the
inactive definition this broke the feature for those users.
Since the varstore doesn't really change that much in the lifecycle of a
VM it usually is okay to simply leave it as is.
Restore the functionality for inactive snapshots by disabling the check.
In the future when uefi snapshotting will be added the rest of the
condition will also be removed.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/460
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Attaching disk into running VM the offline definition may not be
updated and we will end up with that disk existing only in live
definition. Creating snapshot with this state saves both live and
offline definition into snapshot metadata.
When we are deleting an external snapshot we are updating these
definitions in the snapshot metadata so we should just skip over
non-existing disks instead of reporting error.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2174700
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Unify validation of VIR_DOMAIN_FEATURE_HTM, VIR_DOMAIN_FEATURE_NESTED_HV,
VIR_DOMAIN_FEATURE_CCF_ASSIST and remove temporary string.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The features:
QEMU_CAPS_MACHINE_PSERIES_CAP_HPT_MAX_PAGE_SIZE
QEMU_CAPS_MACHINE_PSERIES_CAP_HTM
QEMU_CAPS_MACHINE_PSERIES_CAP_NESTED_HV
QEMU_CAPS_MACHINE_PSERIES_CAP_CCF_ASSIST
QEMU_CAPS_MACHINE_PSERIES_CAP_CFPC
QEMU_CAPS_MACHINE_PSERIES_CAP_SBBC
QEMU_CAPS_MACHINE_PSERIES_CAP_IBS
are supported by all qemu versions that libvirt supports. Drop the
obsolete checks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use automatic pointer freeing, remove 'ret' variable and also remove
return value completely.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Remove useless call to virCapabilitiesFreeMachines as the pointers were
cleared and the unneeded 'ret' variable. Since we don't need to clear
the 'machines' pointer now, remove that as well.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It's never set to any real value. Remove it along with the caching code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Separate the architecture specific code to probe the support for HVF
from the actual setting of the capability.
In upcoming patches 'virQEMUCapsProbeHVF' will be mocked in the
testsuite to provide testing for the HVF hypervisor.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The logic in 'virQEMUCapsInitQMP' invokes a second probe of qemu in case
when acceleration is used and TCG is supported to specifically probe the
CPU and features of non-accelerated guests.
The same logic must then be used in 'qemucapabilitiestest' when
replaying the data for testing otherwise the test would fail.
Export 'virQEMUCapsHaveAccel' for test usage and use the same logic
in 'testQemuCaps'.
Fix the comment in 'virQEMUCapsInitQMP' to outline what's happening.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The changes to the output files are the exact opposite of
those from commit 22207713cf8e: this is proof that the fix is
working as intended, and that existing domains will keep using
raw firmware images regardless of whether or not qcow2 images
are available on the system and have higher priority.
New domains will keep picking whatever firmware is considered
the preferred one according to the order of descriptors, as
evidenced by the fact that the recently introduced
firmware-auto-efi-abi-update-aarch64 test case is unaffected.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The virConnectOpen(), well virConnectOpenInternal() reports an
error if embed root is not an absolute path. This is a fair
requirement, but our qemu_shim doesn't check this requirement and
passes the path to mkdir(), only to fail later on, leaving the
empty directory behind:
$ ls -d asd
ls: cannot access 'asd': No such file or directory
$ virt-qemu-run -r asd whatever.xml
virt-qemu-run: cannot open qemu:///embed?root=asd: unsupported configuration: root path must be absolute
$ ls -d asd
asd
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
After cleanup done in v8.2.0-rc1~47 the
qemuDomainObjExitMonitor() and after v8.7.0-rc1~176 the
qemuDomainObjEnterMonitor() lost the @driver argument. But
corresponding ATTRIBUTE_NONNULL() annotation was not removed and
both functions are still annotated as ATTRIBUTE_NONNULL(2) even
though they accept just one argument (@obj).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Otherwise looking up a secret fails when we try to elevate the identity
in qemuDomainSecretInfoSetupFromSecret.
https://bugzilla.redhat.com/show_bug.cgi?id=2000410
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Suggested-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Even when the user is not taking advantage of firmware
autoselection and instead manually providing all the necessary
information, in most cases they're still going to use firmware
builds that are provided by the OS vendor, are installed in
standard paths and come with a corresponding firmware
descriptor.
Similarly, even when the user is not guiding the autoselection
process by specifying the desired status of certain features
and instead is relying on the system-level descriptor priority
being set up correctly, libvirt will still ultimately decide to
use a specific descriptor, which includes information about the
firmware's features.
In both these cases, take the additional information that were
obtained from the firmware descriptor and reflect them back into
the domain XML, where they can be conveniently inspected by the
user and management applications alike.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that we no longer reject configurations that include both
this information and explicit firmware details, as long of
course as everything is internally consistent, and that we've
ensured that we produce maximally compatible XML on migration,
we can stop stripping this information at the end of the
firmware selection process.
There are several advantages to keeping this information around:
* if the user wants to change the firmware configuration for
an existing VM, they can simply drop the <loader> and
<nvram> elements, tweak the firmware autoselection parameters
and let libvirt pick a firmware that matches on the new
requirements;
* management applications can inspect the XML and easily
figure out firmware-related information without having to
reverse-engineer them based on some opaque paths.
Overall, this change makes things more transparent and easier to
understand. The improvement is so significant that, in a
follow-up commit, we're going to ensure that this information is
available in even more cases.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Right now there are a few scenarios in which we skip ahead, and
removing these exceptions will make for more consistent and
predictable behavior.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The requires-smm feature being present in a firmware descriptor
causes loader.secure=yes to be automatically chosen for the
domain, so we have to avoid this situation or the user's choice
will be silently subverted.
Note that we can't actually encounter loader.secure=no in this
function at the moment because of earlier checks, but that's
going to change soon.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Right now we have checks in place that ensure that explicit
paths are not provided when firmware autoselection has been
enabled, but that's going to change soon.
To prepare for that, take into account user-provided paths
during firmware autoselection if present, and discard all
firmware descriptors that don't contain matching information.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
