Re: [libvirt PATCH 00/17] qemu: Implement external limit manager feature
On Mon, 2021-03-08 at 13:17 +0000, Daniel P. Berrangé wrote:
On Mon, Mar 08, 2021 at 02:11:56PM +0100, Andrea Bolognani wrote:
> The reason why VFIO device assignment is currently not completely
> broken in KubeVirt is that, when the QEMU process is initially
> started, we set the memory locking limit after fork(), so we can do
> that using setrlimit() which doesn't require additional capabilities,
> but in the hotplug scenario libvirtd needs to change the limits of a
> different process: in that case we are forced to use prlimit(), which
> fails due to the lack of CAP_SYS_RESOURCE.
Since you added code to parse existing limits from /proc, I'm wondering
if we can just do without the config option. Simply try to use prlimit
and if it fails, query existing limits to determine if we sould treat
the prlimit as fatal or ignore it. Overall I'd prefer libvirt to
"just work" out of the box rather than requiring people to know about
setting a "make-vfio-hotplug-work=yes" flag in the config file.
The problem with that approach is what to do when *lowering* the
limit, for example as a consequence of hot-unplugging the last VFIO
device from the VM.
If we're controlling the memory locking limit ourselves, then failure
to lower it should be an error, because leaving the limit much higher
than necessary creates potential for DoS by a compromised QEMU; on
the other hand, if the limit is controlled by an external process,
all we can really do is assume they will do the right thing after
hot-unplugging has happened.
I don't think discoverability is too much of an issue, as anyone who
needs to use this option will already have needed to figure out a lot
more in order to effectively take over memory locking limit
management responsibilities from libvirt...
--
Andrea Bolognani / Red Hat / Virtualization