Use g_autoptr for 'vcpuprops' and remove the 'cleanup' label and 'ret'
varlaible which is no longer needed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Report the error from 'qemuValidateDomainWatchdogDef' rather than
'qemuBuildWatchdogDevStr'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The flag will be used to switch use of JSON arguments for -device once
qemu will support it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The flag will be used to switch use of JSON arguments for -chardev once
qemu will support it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The returned argument list is a NULL-terminated string list and the only
caller doesn't use the count. Remove the argument.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Optimize the number of string copies by using the virBuffers in the
callers directly. Simplest way to achieve this is to just open code the
one function call 'virQEMUBuildDriveCommandlineFromJSON' was wrapping
in the two callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The -netdev formatter code switched to a real virQEMUCaps flag so we can
remove the old flags which used to enable JSON for -netdev for
validation purposes.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that everything was replaced by the new code we can remove this
function.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Base the JSON output on a regular capability flag rather than purely
internal flag. This will prepare for the time when QEMU will accept JSON
argumets for -netdev.
For now the capability is not set (thus we for now don't have QMP
schema validation) but that will be addressed later.
To achieve this 'qemuBuildNetdevCommandlineFromJSON' is introduced
and all callers of 'virQEMUBuildNetdevCommandlineFromJSON' are
refactored to use the new helper.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We validate the generated props against the QMP schema which makes sure
that the objects are generated properly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce a capability that will be asserted once '-netdev' will accept
JSON. For now it will be dormant (only used by tests).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Unify it with the upcoming capabilities for -netdev and -device.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All callers basically end up dumping the buffer into a string and then
adding '-object' 'props' arguments to virCommand. Simplify all callers
by doing this in the function itself.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Input devices of VIR_DOMAIN_INPUT_TYPE_EVDEV type are instantiated via
an '-object' rather than a '-device'. Mixing them in one function is a
bad idea as the caller then needs to use the string correctly which is
not the case in 'qemuDomainAttachInputDevice'.
Generate a JSON object for '-object' explicitly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rename the function to 'qemuBuildMemoryCellBackendProps' and return the
properties before conversion to commandline arguments. This requires
changes in the caller.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Enforce that the ':' separator between the key and value is always
present.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In many cases we use a signed value, but use the sign to note that it
was not assigned. For converting to JSON objects it will be handy to
have possibility to do this automatically.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit 58ba0f6a3d7342fba29edbbf2bb9cb5497c870e5 added a capability which
is supported by all qemu versions we support. Remove it and the
associated dead code. Since the capability isn't present in any upstream
release we can delete it completely.
Specifically the commit itself states that it was introduced "around
(qemu) 2.1". The rest of the code handles properly that the feature is
used only on x86 with the i440fx machine so the capability is pointless.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The error that "acpi-bridge-hotplug" is not supported would be triggered
only if both the ICH9 and PIIX don't support the capability and the
machine is q35. This makes no sense.
We want to check that the appropriate platform supports the appropriate
feature.
Fixes: 7300ccc9b3e
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This change adds backend qemu command line support for new libvirt
global feature 'acpi-bridge-hotplug'. This option can be used as
following:
<feature>
<pci>
<acpi-bridge-hotplug state='off|on'/>
</pci>
</feature>
The '<pci>' sub-element under '<feature>' is also newly introduced.
'acpi-bridge-hotplug' turns on the following command line option to
qemu for x86 guests:
(pc): -global PIIX4_PM.acpi-pci-hotplug-with-bridge-support=<off|on>
(q35): -global ICH9-LPC.acpi-pci-hotplug-with-bridge-support=<off|on>
This change also adds the required qemuxml2argv unit tests in order to
test correct qemu arguments. Unit tests have also been added to test
qemu capability validation checks as well as checks for using this
option with the right architecture.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Laine Stump <laine@redhat.com>
This change introduces a new libvirt sub-element <pci> under
<features> that can be used to configure all pci related features.
Currently the only sub-sub element supported by this sub-element is
'acpi-bridge-hotplug' as shown below:
<features>
<pci>
<acpi-bridge-hotplug state='on|off'/>
</pci>
</features>
The above option is only available for the QEMU driver, for x86 guests
only. It is a global option, affecting all PCI bridge controllers on
the guest.
The 'acpi-bridge-hotplug' option enables or disables ACPI hotplug
support for cold-plugged pci bridges. Examples of bridges include the
PCI-PCI bridge (pci-bridge controller) for pc (i440fx) machinetypes,
or PCIe-PCI bridges and pcie-root-port controllers for q35
machinetypes.
For pc machinetypes in x86, this option has been available in QEMU
since version 2.1. Please see the following changes in qemu repo:
9e047b982452c6 ("piix4: add acpi pci hotplug support")
133a2da488062e ("pc: acpi: generate AML only for PCI0 devices if PCI
bridge hotplug is disabled")
For q35 machinetypes, this was introduced in QEMU 6.1 with the
following changes in qemu repo:
(a) c0e427d6eb5fef ("hw/acpi/ich9: Enable ACPI PCI hot-plug")
(b) 17858a16950860 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on
Q35")
The reasons for enabling ACPI based hotplug for PCIe (q35) based
machines (as opposed to native hotplug) are outlined in (b). There are
use cases where users would still want to use native
hotplug. Therefore, this config option enables users to choose either
ACPI based hotplug or native hotplug for bridges (for example for pcie
root port controller in q35 machines).
Qemu capability validation checks have also been added along with
related unit tests to exercise the new conf option.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Laine Stump <laine@redhat.com>
qemu added support for i440fx specific global boolean flag
PIIX4_PM.acpi-pci-hotplug-with-bridge-support
around version 2.1. This flag is enabled by default. When disabled, it
turns off acpi pci hotplug for cold plugged pci bridges in i440fx
machine types.
Very recently, in qemu version 6.1, the same global option was also
added for q35 machine types as well.
ICH9-LPC.acpi-pci-hotplug-with-bridge-support
This option turns on or off acpi based hotplug for cold plugged pcie
bridges like pcie root ports. This flag is also enabled by
default. Please refer to the following qemu changes:
c0e427d6eb5fef ("hw/acpi/ich9: Enable ACPI PCI hot-plug")
17858a16950860 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on Q35")
This patch adds the corresponding qemu capabilities in libvirt. For
i440fx, the capability is detected as
QEMU_CAPS_PIIX_ACPI_HOTPLUG_BRIDGE. For q35, the capability is
detected as QEMU_CAPS_ICH9_ACPI_HOTPLUG_BRIDGE.
Please note that the test specific qemu capabilities .replies files
has already been updated as a part of regular refreshing them when a
new qemu version is released. Hence, no updates to those files are
required.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Laine Stump <laine@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>
With cgroup v1 I'm seeing LXC container startup failures:
$ sudo virt-install --connect lxc:/// --name test-container --memory 128
--boot init=/bin/sh
Starting install...
ERROR error from service:
GDBus.Error:org.freedesktop.machine1.NoMachineForPID: PID 2145047 does
not belong to any known machine
libvirt 7.0.0 works but 7.1.0+ does not. The root error seems to predate
that, showing up in syslog, but commit 9c1693eff made it fatal:
commit 9c1693eff427661616ce1bd2795688f87288a412
Author: Pavel Hrdina <phrdina@redhat.com>
Date: Fri Feb 5 16:17:35 2021 +0100
vircgroup: use DBus call to systemd for some APIs
The error comes from virSystemdGetMachineByPID. The PID that shows up in
the above error message does not match the leader PID as reported by
machinectl.
This change fixes the error. Things seem to continue to work with
cgroupsv2 after this change.
https://gitlab.com/libvirt/libvirt/-/issues/182
Tested-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Other devices (includes 9p-based fsdev) call this wrapper
before formatting the device.
Add it here too.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This reverts commit 801e6da29c0202946d44b42136cc4ee229932a29
They are not needed anymore.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reconstruct the socket path from priv->libDir in every user.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Intended as a replacement for qemuVirtioFSCreateSocketFilename,
to be used outside of qemu_virtiofs.c
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The commit adding the vhost-user-fs device forgot to format
the device's alias on the command line.
Thankfully it was not needed yet because virtiofs migration
is not yet supported, but it will be needed in the future
to allow hot(un)plug.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@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 capability name piix4-acpi-root-hotplug-en is not conventional and
appreared to be confusing to some. "en" suffix is also incorrect as the
capability in qemu is used to both enable and disable hotplug on the pci root
bus on the i440fx. Hence, rename it to piix4.acpi-root-pci-hotplug so that it
is clearer, less confusing and more accurate.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Laine Stump <laine@redhat.com>
Also introduces a G_DEFINE_AUTOPTR_CLEANUP_FUNC for virCHMonitor.
Signed-off-by: William Douglas <william.douglas@intel.com>
Reviewed-by: Laine Stump <laine@redhat.com>
It is already being unrefed in virCHMonitorDispose().
Signed-off-by: William Douglas <william.douglas@intel.com>
Reviewed-by: Laine Stump <laine@redhat.com>
In virCHMontiorNew the monitor object was referenced an additional
time incorrectly preventing it from being disposed of, and wasn't
always closed properly on failure.
Signed-off-by: William Douglas <william.douglas@intel.com>
Reviewed-by: Laine Stump <laine@redhat.com>
In virCHMonitorBuildKernelRelatedJson there are two cases of json
value objects being lost after the pointer being redefined. This
change removes the needless redefinition.
Signed-off-by: William Douglas <william.douglas@intel.com>
Reviewed-by: Laine Stump <laine@redhat.com>
This change adds qemu backend command line support for enabling or disabling
hotplug on the pci-root controller using the 'target' sub-element of the
pci-root controller as shown below:
<controller type='pci' model='pci-root'>
<target hotplug='off'/>
</controller>
'<target hotplug='off/on'/>' is only valid for pc (i440fx-based x86)
machinetypes and turns on the following command line option that is passed
to qemu for x86 guests:
-global PIIX4_PM.acpi-root-pci-hotplug=<off/on>
Before introduction of this attribute, hotplug was always enabled for
pci-root of an i440fx-based machinetype, and since its introduction
the default setting has always been "on" for those machinetypes.
This change also adds the required qemuxml2argv unit tests in order to test
correct qemu arguments. Unit tests have also been added to test qemu capability
validation checks.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
This change introduces libvirt xml support to enable/disable hotplug on the
pci-root controller. It adds a 'target' subelement for the pci-root controller
with a 'hotplug' property. This property can be used to enable or disable
hotplug for the pci-root controller. For example, in order to disable hotplug
on the pci-root controller, one has to use set '<target hotplug='off'>' as
shown below:
<controller type='pci' model='pci-root'>
<target hotplug='off'/>
</controller>
'<target hotplug='on'>' option would enable hotplug for pci-root controller.
This is also the default value. This option is only available for pc machine
types and is applicable for qemu/kvm accelerator only.This feature was
introduced from qemu version 5.2 with the following change in qemu repository:
3d7e78aa7777f ("Introduce a new flag for i440fx to disable PCI hotplug on the root bus")
The above qemu commit describes some reasons why users might to disable hotplug
on PCI root buses.
Related unit tests to exercise the new conf option has also been added.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
The following change in qemu added support for a global boolean flag specific
to i440fx machines that would turn off or on acpi based hotplug for pci root
bus:
3d7e78aa7777f ("Introduce a new flag for i440fx to disable PCI hotplug on the root bus")
The option is passed as "-global PIIX4_PM.acpi-root-pci-hotplug=on" etc in qemu
commandline. It is enabled by default. This patch adds the corresponding qemu
capabilities in libvirt as QEMU_CAPS_PIIX_ACPI_ROOT_PCI_HOTPLUG.
Please note that the test specific qemu capabilities .replies files has already
been updated as a part of regular refreshing them when a new qemu version is
released. Hence, no updates to those files are required.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Laine Stump <laine@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>
