Re: [libvirt PATCH 00/16] Add support for persistent mediated devices
On Thu, Jul 16, 2020 at 05:21:30PM -0500, Jonathon Jongsma wrote:
This patch series follows the previously-merged series which added
support for
transient mediated devices. This series expands mdev support to include
persistent device definitions. Again, it relies on mdevctl as the backend.
It follows the common libvirt pattern of APIs by adding the following new APIs
for node devices:
- virNodeDeviceDefineXML() - defines a persistent device
- virNodeDeviceUndefine() - undefines a persistent device
- virNodeDeviceCreate() - starts a previously-defined device
It also adds virsh commands mapping to these new APIs: nodedev-define,
nodedev-undefine, and nodedev-start.
The method of staying up-to-date with devices defined by mdevctl is currently a
little bit crude due to the fact that mdevctl does not emit any events when new
devices are added or removed. As a workaround, we create a file monitor for the
mdevctl config directory and re-query mdevctl when we detect changes within
that directory. In the future, mdevctl may introduce a more elegant solution.
In general, I don't think it is desirable for libvirt to monitor the
configuration directory for changes made outside of libvirt and expect libvirt
to keep up with the new configuration and still be able manage the device.
I'd say that we only manage devices that we created and have control over.
Everything else is outside libvirt's scope to handle (the same goes for
persistent device removals).
If a device cannot be created, because mdevctl already has a colliding device
that was created outside of libvirt, we should document that the user is
expected to remove the device configuration and re-create it with libvirt -
let's say mdevctl adds support for an alternative config dir, how does libvirt
know it should monitor that one instead /etc/mdev.d?
All summed up, until there's some event signalling in mdevctl, we should only
support devices we previously defined.
Regards,
Erik