On Wed, Nov 04, 2015 at 12:36:58 -0500, Laine Stump wrote: > On 11/04/2015 10:54 AM, Peter Krempa wrote: > > On Wed, Nov 04, 2015 at 08:43:34 -0700, Alex Williamson wrote: > >> 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) But even if you somehow discover what IO space a device needs you still need to have an idea about the memory required to run a domain without this device and that is impossible to compute. So unless QEMU is clever enough to only lock memory used as the IO space, there's not much we can do, I'm afraid. As Peter said, anyone who doesn't want this unlimited behavior can always set memory hard limits for their domains. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list