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)
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list