On Mon, Mar 13, 2017 at 12:35:42PM -0400, Luiz Capitulino wrote: > On Mon, 13 Mar 2017 16:08:58 +0000 > "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote: > > > > 2. Drop change c2e60ad0e51 and automtically increase memory > > > locking limit to infinity when seeing <memoryBacking><locked/> > > > > > > pros: make all cases work, no more <hard_limit> requirement > > > > > > cons: allows guests with <locked/> to lock all memory > > > assigned to them plus QEMU allocations. While this seems > > > undesirable or even a security issue, using <hard_limit> > > > will have the same effect > > > > I think this is the only viable approach, given that no one can > > provide a way to reliably calculate QEMU peak memory usage. > > Unless we want to take guest RAM + $LARGE NUMBER - eg just blindly > > assume that 2 GB is enough for QEMU working set, so for an 8 GB > > guest, just set 10 GB as the limit. > > Better to set it to infinity and be done with it. Not neccessarily, no. If we set $RAM + $LARGE_NUMBER, we are still likely to be well below the overall physical RAM of a host. IOW, a single compromised QEMU would still be restricted in how much it can pin. If we set it to infinity then a compromised QEMU can lock all of physical RAM doing a very effective DOS on the host, as it can't even swap the guest out to recover. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
