It is possible for 'mdevctl' to output nothing, an empty string
(e.g. when no mediated devices are defined on the host). What is
weird is that when passing '--defined' then 'mdevctl' outputs an
empty JSON array instead. Nevertheless, we should accept both and
treat them the same, i.e. as no mediated devices.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/523
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
nodeDeviceUpdateMediatedDevices invokes virMdevctlListDefined and
virMdevctlListActive both of which were passed the same 'errmsg' buffer.
Since virCommandSetErrorBuffer() always allocates the error buffer one
of them was leaked.
Fix it by populating the 'errmsg' buffer only on failure of
virMdevctlListActive|Defined which invoke the command.
Add a comment to nodeDeviceGetMdevctlListCommand reminding how
virCommandSetErrorBuffer() works.
Fixes: 44a0f2f0c8f
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
All services are ordered after local-fs.target unless they have set
DefaultDependencies=no, which we do not do.
https://gitlab.com/libvirt/libvirt/-/issues/489
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Since commit 44a0f2f0, we now query mdevctl for transient (active) mdevs
in order to gather attributes for the mdev. Unfortunately, this commit
introduced a regression because nodeDeviceUpdateMediatedDevice() assumed
that all mdevs returned from mdevctl were actually persistent mdevs but
we were using it to update transient mdevs. Refactor the function so
that we can use it to update both persistent and transient mdevs.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Rather than directly executing mdevctl from the udev event thread when
we determine that we need to re-query, schedule the mdevctl thread to
run. This also helps to coalesce multiple back-to-back updates into a
single one when there are multiple updates in a row or at startup when a
host has a very large number of mdevs.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Factor out a new scheduleMdevctlUpdate() function so that we can re-use
it from other places. Now that other events can make it necessary to
re-query mdevctl for mdev updates, this function will be useful for
coalescing multiple updates in quick succession into a single mdevctl
query.
Also rename a couple functions. The names weren't very descriptive of
their behavior. For example, the old scheduleMdevctlHandler() function
didn't actually schedule anything, it just started a thread. So rename
it to free up the 'schedule' name for the above refactored function.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Update the optional mdev attributes by running an mdevctl update on a
new created nodedev object representing an mdev.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2143158
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Our CI started to enable udev backend on FreeBSD. And while there
is udev on FreeBSD some parts of our code are highly Linux
specific, e.g. translating SCSI device type to string (from an
integer obtained from the sysfs). Obviously, this doesn't work
anywhere else. This is the reason why we need to include
scsi/scsi.h header file (which actually comes from the Linux
kernel source tree but for some reason glibc started to
distribute it, followed by musl).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Instead of updating defined mdevs only add another update for active
devices as well to cover transient mdev devices as well.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2143158
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
The parameter was added for consistency with virPidFileAcquirePath.
However, all callers of virPidFileAcquire pass false.
Remove the argument.
Partially-reverts: 2250a2b5d21c3b3529727f38a99cba22f84024f7
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Certain udev entries might be of a size that makes libudev emit EINVAL
which right now leads to udevEventHandleThread exiting. Due to no more
handling events other elements of libvirt will start pushing for events
to be consumed which never happens causing a busy loop burning a cpu
without any gain.
After evaluation of the example case discussed in in #245 and a test
run ignoring EINVAL it was considered safe to add EINVAL to the ignored
errnos to not exit udevEventHandleThread giving it more resilience.
The root cause is in systemd and by now was discussed and fixed via
https://github.com/systemd/systemd/issues/24987, but hardening libvirt
to be able to better deal with EINVAL returned still is the right thing
to avoid the reported busy loops on systemd with older systemd versions.
Fixes: https://gitlab.com/libvirt/libvirt/-/issues/245
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Allow callers to request XML validation against the schema. All callers
for now pass 'false'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
The node_device_driver.h declares nodeDeviceLock() and
nodeDeviceUnlock() functions which used to exist, but after
rework to automatic mutex management they exist no more. Their
last use was removed in v8.1.0-rc1~122.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Currently, udevNodeRegister() is forward declared in
node_device_driver.h even though the function is implemented in
node_device_udev.c which warrants node_device_udev.h header file.
Move the declaration into the correct file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Nothing in the header file requires the include of libudev.h, as
the former header file is now empty.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
The DMI_DEVPATH macro is used exclusively within
node_device_udev.c. There's no need to expose it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
The SYSFS_DATA_SIZE macro is Unused since its introduction in
v0.7.3~48. Sorry Dave.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Replace the thin wrappers virNodeDeviceDefParseString/File by directly
calling the main parser.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Upcoming patch which is fixing the opening of drivers in monolithic mode
needs to know whether we are inside 'libvirtd' but the code where the
decision needs to happen is not re-compiled per daemon. Thus we need to
pass this information to the stateful driver init function so that it
can be remebered.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Openstack developers reported that newly-created mdevs were not
recognized by libvirt until after a libvirt daemon restart. The source
of the problem appears to be that when libvirt gets the udev 'add'
event, the sysfs tree for that device might not be ready and so libvirt
waits 100ms for it to appear (max 100 waits of 1ms each). But in the
OpenStack environment, the sysfs tree for new mediated devices was
taking closer to 250ms to appear and therefore libvirt gave up waiting
and didn't add these new devices to its list of nodedevs.
By changing the wait time to 1 second (max 100 waits of 10ms each), this
should provide enough time to enable these deployments to recognize
newly-created mediated devices, but it shouldn't increase the delay for
more traditional deployments too much.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2109450
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
It would be nice to be able to test the mediated device capabilities
without having physical hardware which supports it. The 'mtty' kernel
module presents a virtual parent device which is capable of creating
'fake' mediated devices, and as such it would be useful for testing.
However, the 'mtty' device is not part of an existing device subsystem
(e.g. PCI, etc), so libvirt ignores it and it does not get added to the
node device list. And because it does not get added to the node device
list, it cannot be used to create child mdevs using `virsh
nodedev-create`.
There is already a node device type capability
VIR_NODE_DEV_CAP_MDEV_TYPES that indicates whether a device supports
creating child mediated devices, but libvirt assumes that this is a
nested capability (in other words, it assumes that the primary
capability of a device is something like PCI). If we allow this
MDEV_TYPES capability to be a primary device capability, then we can
support virtual devices like 'mtty' as a parent for mediated devices.
See https://bugzilla.redhat.com/show_bug.cgi?id=2107031
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As "none" is a legal value represented in the sysfs attribute dev_busid
this patch prevents libvirt from incorrectly reporting an internal error.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Suggested-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add the new introduced sysfs attribute dev_busid which provides the address
of the device in the subchannel independent from the bound device driver.
It is added if available in the sysfs as optional channel_dev_addr element into
the css device capabilty providing the ccw deivce address attributes cssid,
ssid and devno.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add virCCWDeviceAddressParseFromString and use it in nodedev udev.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Move virDomainCCWAddressAsString into virccw and rename method as
virCCWDeviceAddressAsString.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Refactor ccw data structure virDomainDeviceCCWAddress into util virccw.h
and rename it as virCCWDeviceAddress.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When nodedev objects are added and removed if possible check if mdev-types is
supported by the object and trigger a mdev device definition update to correct
the associated parent nodedevs.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
The parent of the mdev definition can change due to the existance of the
parent device. The parents existance can e.g. depend on the device
driver load state.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
There are few places where a virPCIDeviceAddress typed variable
is allocated on the stack but it's not initialized. This can lead
to random values of its members which in turn can lead to a
random behaviour.
Generated with help of the following spatch:
@@
identifier I;
@@
- virPCIDeviceAddress I;
+ virPCIDeviceAddress I = { 0 };
And then fixing bhyveAssignDevicePCISlots() which does declare
the variable and then explicitly zero it by calling memset() only
to set a specific member afterwards.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
We recently started listing these in the spec file and, since we
were not creating them during the installation phase, that broke
RPM builds.
Fixes: 4b43da0bff9b78dcf1189388d4c89e524238b41d
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The service files were copied out of the service file for libvirtd and
the name of the corresponding manpage was not fixed.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2045959
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Unfortunately, udev doesn't set ID_TYPE attribute for NVMe disks,
therefore we have to add another case into udevKludgeStorageType()
to treat /dev/nvme* devlinks as any other disk.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2045953
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The udevKludgeStorageType() function looks at devlink name
(/dev/XXX) and guesses the type of the (storage) device using a
series of STRPREFIX() calls. Well those can be turn into an array
and a for() loop, especially if we are about to add a new case
(in the next commit).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
sysconfig files are owned by the admin of the host. They have the
liberty to put anything they want into these files. This makes it
difficult to provide different built-in defaults.
Remove the sysconfig file and place the current desired default into
the service file.
Local customizations can now go either into /etc/sysconfig/name
or /etc/systemd/system/name.service.d/my-knobs.conf
Attempt to handle upgrades in libvirt.spec.
Dirty files which are marked as %config will be renamed to file.rpmsave.
To restore them automatically, move stale .rpmsave files away, and
catch any new rpmsave files in %posttrans.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
One of the paths returned -1 directly without going through the cleanup
section.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
* XML serialization and deserialization of PCI VPD;
* PCI VPD capability flags added and used in relevant places;
* XML to XML tests for the added capability.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
Implement these new API functions in the nodedev driver.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Since UUID is not guaranteed to be unique by mdevctl, we may have more
than one nodedev with the same UUID. Therefore, we need to disambiguate
when looking up mdevs by specifying the UUID and parent address, which
mdevctl guarantees to be a unique combination.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Unfortunately, mdevctl supports defining more than one mdev with the
same UUID as long as they have different parent devices. (Only one of
these devices can be active at any given time).
This means that we can't use the UUID alone as a way to uniquely
identify mdev node devices. Append the parent address to ensure
uniqueness. For example:
Before: mdev_88a6b868_46bd_4015_8e5b_26107f82da38
After: mdev_88a6b868_46bd_4015_8e5b_26107f82da38_0000_00_02_0
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1979440
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This can be used similarly to other postparse callbacks in libvirt --
filling in additional information that can be determined by using the
information provided in the XML. In this case, we determine the address
of the parent device and cache it in the mdev caps so that we can use it
for generating a unique name and interacting with mdevctl.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
At the moment, this is only for mediated devices. When a new mediated
device is created or defined, the xml is expected specify the nodedev
name of an existing device as its parent. We were not previously
validating this and were simply accepting any string here.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
