Peter Krempa [Mon, 4 Oct 2021 12:44:09 +0000 (14:44 +0200)]
qemu: validate: Move disk address validation code
Move the code from 'qemuValidateDomainDeviceDefDiskFrontend' into
'qemuValidateDomainDeviceDefAddressDrive' which is called from
'qemuValidateDomainDeviceDefAddress' so that we have all address
validation code together.
This also allows us to remove the inline validation inside
'qemuBuildSCSIHostdevDevStr'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Fri, 1 Oct 2021 20:28:59 +0000 (22:28 +0200)]
qemuBuildHostdevCommandLine: Format PCI host devices via JSON
For properties we use these are the QEMU types:
host=<str> - Address (bus/device/function) of the host device, example: 04:10.0
bootindex=<int32>
failover_pair_id=<str>
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 30 Sep 2021 16:07:29 +0000 (18:07 +0200)]
qemuBuildRNGCommandLine: Generate via JSON
The 'virtio-rng' has the following property types according to QEMU:
rng=<link<rng-backend>>
max-bytes=<uint64> - (default: 9223372036854775807)
period=<uint32> - (default: 65536)
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 30 Sep 2021 15:55:49 +0000 (17:55 +0200)]
qemuBuildMemballoonCommandLine: Generate via JSON
The generated properties have the following types according to QEMU:
deflate-on-oom=<bool> - on/off (default: false)
free-page-reporting=<bool> - on/off (default: false)
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Mon, 27 Sep 2021 17:26:32 +0000 (19:26 +0200)]
qemuBuildShmemCommandLine: Generate via JSON
Note that the legacy 'ivshmem' device was already removed upstream, but
it's converted so that the code is identical.
For the two modern devices QEMU considers the properties being of
following types:
'ivshmem-doorbell'
chardev=<str> - ID of a chardev to use as a backend
ioeventfd=<bool> - on/off (default: true)
master=<OnOffAuto> - on/off/auto (default: "off")
vectors=<uint32> - (default: 1)
Peter Krempa [Fri, 1 Oct 2021 20:18:39 +0000 (22:18 +0200)]
qemu: command: Introduce JSON variant of qemuBuildRomProps
Add a JSON variant of the generator 'rom' properties. For convenience
both the old and new are for now marked as unused, which will be removed
once the conversion is complete.
The formatted properties have following types according to QEMU.
'virtio-blk-pci' was used as an example:
rombar=<uint32> - (default: 1)
romfile=<str>
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Sat, 25 Sep 2021 07:08:05 +0000 (09:08 +0200)]
qemu: command: Introduce helper for building JSON props of -device into commandline
The helper converts the JSON object to a string and adds it to the
current command as arguments of '-device'. The helper also prepares for
'-device' taking JSON directly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 30 Sep 2021 15:55:45 +0000 (17:55 +0200)]
qemu: command: Introduce JSON variant of qemuBuildVirtioDevStr
Add a JSON variant of the generator of properties for virtio devices.
For convenience both the old and new are for now marked as unused, which
will be removed once the conversion is complete.
The formatted properties have following types according to QEMU.
'virtio-blk-pci' was used as an example:
Peter Krempa [Fri, 1 Oct 2021 14:47:12 +0000 (16:47 +0200)]
qemu: validate: Move validation of device rom
Move the validation from 'qemuBuildRomStr' into the function which
validates device info. It was originally named
'qemuValidateDomainDeviceDefAddress' but this commit renames it to
'qemuValidateDomainDeviceDefInfo'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit ffda44030a2 added validation of the 'acpiIndex' field in
virDomainDeviceInfo by calling 'virDomainDeviceInfoIterate' from
'qemuValidateDomainDef'. This is overly complicated we have
'qemuValidateDomainDeviceDef' which is already called for every single
device so we can avoid the extra loop.
Restructure the code by calling 'qemuValidateDomainDeviceInfo' directly
from 'qemuValidateDomainDeviceDef' and avoid unnecessary calls to
'virDomainDeviceGetInfo' by calling 'qemuValidateDomainDeviceDefAddress'
from 'qemuValidateDomainDeviceInfo'
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Fri, 1 Oct 2021 14:18:13 +0000 (16:18 +0200)]
qemu: Use 'effectiveBootIndex' to handle <os><boot dev='network'>
Fill in the effective boot index for network devices (or hostdev-backed
network devices via 'qemuProcessPrepareDeviceBootorder'. This patch
doesn't clean up the cruft to make it more obvious what's happening.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Fri, 1 Oct 2021 13:16:57 +0000 (15:16 +0200)]
conf: Introduce 'effectiveBootIndex' into 'virDomainDeviceInfo'
'effectiveBootIndex' is a copy of 'bootIndex' if '<boot order=' was
present and left unassigned if not. This allows hypervisor drivers to
reinterpret <os><boot> without being visible in the XML.
QEMU driver had a internal implementation for disks, which is now
replaced. Additionally this will simplify a refactor of network boot
assignment.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 30 Sep 2021 15:27:35 +0000 (17:27 +0200)]
qemuBuildVirtioDevStr: Remove 'baseName' argument
The code doesn't need the name as it determines it internally. Remove
the argument and fix all callers. In certain cases it led to
simplification of the logic.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 30 Sep 2021 11:27:13 +0000 (13:27 +0200)]
qemuBuildVirtioDevGetConfigDev: Provide more information
Since we already have code for per-device behaviour we can also populate
the device name and extract virtioOptions in the switch statement so
that callers don't have to pass it in.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'virtio' argument was misleadingly implying that it's true for all
virtio devices, but that's not the case. 'virtio-vga(-gl)' is a virtio
device but doesn't accept the usual bus-dependant suffix.
Add a comment for 'qemuDeviceVideoGetModel' and another boolean
'virtioBusSuffix' which carries the above meaning so that the 'virtio'
argument can be fixed (it will be used later).
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Thu, 30 Sep 2021 08:29:35 +0000 (10:29 +0200)]
qemuBuildVirtioDevStr: Extract code for determining device model
Extract the code into 'qemuBuildVirtioDevGetConfig' so that we can
later reuse it when converting individual device code into the more
modern JSON approach as the extracted code will be necessary either way.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Fri, 26 Mar 2021 14:43:14 +0000 (15:43 +0100)]
qemu: command: Introduce JSON equivalent of qemuBuildDeviceAddressStr
Upcoming patches will start converting the formatting of arguments for
-device from a string to JSON so that we can keep proper types around
when using it via QMP.
This means we will need an equivalet for the device address builder
function. 'qemuBuildDeviceAddressProps' provides equal functionality,
but the output differs for fields where a number is expected, where
we've previously formatted a hex value but now end up with a decimal
value per JSON standard.
For given address types I've selected an example device and used
'-device $DEV,help' to obtain the current types recognized by qemu:
Note that 'bus' is not shown below, but it's already a string so we can
keep using it as a string.
VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI (virtio-balloon-pci)
acpi-index=<uint32> - (default: 0)
addr=<int32> - Slot and optional function number, example: 06.0 or 06 (default: -1)
multifunction=<bool> - on/off (default: false)
Note that 'addr' is here defined as 'int32' but in fact internally in
qemu is an alternate type between a number and a string so we can keep
using strings here.
Peter Krempa [Sat, 25 Sep 2021 07:04:55 +0000 (09:04 +0200)]
virQEMUBuildCommandLineJSONRecurse: Error out when array conversion function is not provided
For conversion of '-device' we'll try to avoid usage of arrays if
possible, so for now if the array coversion function is not provided the
convertor will error out.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Prevent duplication of code when extending the validator for new
commands. Add a struct describing a command to validate and make the
validation loop a bit more robust to corner cases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Wed, 24 Mar 2021 13:00:07 +0000 (14:00 +0100)]
virQEMUBuildDriveCommandlineFromJSON: Open-code in callers
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>
Peter Krempa [Fri, 24 Sep 2021 17:15:22 +0000 (19:15 +0200)]
qemu: Remove 'qemuBuildCommandLineFlags' and associated code
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>
Peter Krempa [Fri, 24 Sep 2021 16:47:59 +0000 (18:47 +0200)]
qemu: command: Format netdev as JSON when QEMU_CAPS_NETDEV_JSON is present
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>
Peter Krempa [Fri, 24 Sep 2021 16:58:33 +0000 (18:58 +0200)]
testCompareXMLToArgvValidateSchema: Base -netdev validation on JSON
Base the validation on presence of JSON as we do with other validated
commands. This will prepare the code for a refactor so that it's the
same for all validated commands.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Fri, 24 Sep 2021 14:15:38 +0000 (16:15 +0200)]
qemuBuildObjectCommandlineFromJSON: Format directly into the virCommand
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>
Peter Krempa [Fri, 24 Sep 2021 13:52:03 +0000 (15:52 +0200)]
qemuBuildInputDevStr: Don't mix generators for -object and -device
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>
Peter Krempa [Fri, 24 Sep 2021 13:37:17 +0000 (15:37 +0200)]
qemuBuildMemoryCellBackendStr: Return JSON props instead of a buffer
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>
Peter Krempa [Tue, 5 Oct 2021 12:07:31 +0000 (14:07 +0200)]
virJSONValueObjectAddVArgs: Add 'k' convertor for formatting non-negative integers
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>
Peter Krempa [Mon, 11 Oct 2021 12:30:58 +0000 (14:30 +0200)]
qemuxml2argvtest: Use real-caps testing for 'acpi-hotplug-bridge-disable'
We can use real example configs to prove the support without the
need for using fake capabilities. Fix the recently added test cases.
The negative case for 'pc-i440fx-acpi-hotplug-bridge-disable' is removed
completely as there is no real qemu libvirt supports which wouldn't
have the capability.
The input file for the negative test on aarch64 is modified so that it's
actually a reasonably valid VM config.
Fixes: bef0f0d8be6 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>
If running multiple [1] clusters (uncommon) the ceph config file will be
derived from the cluster name. Therefore the rule to allow to read ceph
config files need to be opened up slightly to allow for that condition.
Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1588576 Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
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>
Ani Sinha [Fri, 8 Oct 2021 06:42:13 +0000 (12:12 +0530)]
conf: introduce support for acpi-bridge-hotplug feature
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:
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>
vireventglib: Remove handles with the highest priority
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>
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>
Jim Fehlig [Wed, 6 Oct 2021 04:34:57 +0000 (22:34 -0600)]
tools: Fix virt-host-validate SEV detection
virt-host-validate checks if AMD SEV is enabled by verifying
/sys/module/kvm_amd/parameters/sev is set to '1'. On a system
running kernel 5.13, the parameter is reported as 'Y'. To be
extra paranoid, add a check for 'y' along with 'Y' to complement
the existing check for '1'.
Fixes: https://bugzilla.opensuse.org/show_bug.cgi?id=1188715 Signed-off-by: Jim Fehlig <jfehlig@suse.com> Reviewed-by: Andrea Bolognani <abologna@redhat.com>
projects / libvirt.git / log