[libvirt] [PATCH] qemu: process: Fix automatic setting of locked memory limit for VFIO

[Laine Stump]

On 11/04/2015 10:54 AM, Peter Krempa wrote:
> On Wed, Nov 04, 2015 at 08:43:34 -0700, Alex Williamson wrote:
>> On Wed, 2015-11-04 at 16:14 +0100, Peter Krempa wrote:
>>> For VFIO passthrough the guest memory including the device memory to be
>>> resident in memory. Previously we used a magic constant of 1GiB that we
>>> added to the current memory size of the VM to accomodate all this. It is
>>> possible though that the device that is passed through exposes more than
>>> that. To avoid guessing wrong again in the future set the memory lock
>>> limit to unlimited at the point when VFIO will be used.
>>>
>>> This problem is similar to the issue where we tried to infer the hard
>>> limit for a VM according to it's configuration. This proved to be really
>>> problematic so we moved this burden to the user.
>>>
>>> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1273480
>>>
>>> Additionally this patch also fixes a similar bug, where the mlock limit
>>> was not increased prior to a memory hotplug operation.
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1273491
>>> ---
>> IOW, tracking how much memory a VM should be able to lock is too hard,
>> let's circumvent the security that the kernel is trying to add here and
>> let assigned device VMs again lock as much memory as they want.  This
>> may solve some bugs, but it does so by ignoring the security limits
>> we're trying to impose.  Thanks,
> Well, the default here is 64KiB, which obviously is not enough in this
> case and we are trying to set something reasonable so that it will not
> break. Other option would be to force the users to specify <hard_limit>
> so that they are hold responsible for the value.
>
> So the actual question here is: Is there a 100% working
> alogrithm/formula that will allow us to calculate the locked memory
> size any point/configuration? I'll happily do something that.
>
> We tried to do a similar thing to automatically infer the hard limit
> size. There were many bugs resultin of this since we weren't able to
> accurately guess qemu's memory usage.
>
> Additionally if users wish to impose a limit on this they still might
> want to use the <hard_limit> setting.

I also don't like the idea of having libvirt automatically give the 
ability to lock all memory in RAM to every process that needs an 
assigned device, so I would rather see "some kind of reasonable limit" 
by default, along with the ability to increase it when necessary.

(seriously, though, "the amount of IO space required by this device" 
sounds like something that should be discoverable. Of course if it is, 
then I should have been ambitious enough to figure that out in the first 
place so that we wouldn't have this problem now :-P)