[libvirt] [BUG] mlock support breakage

Libvirt commit c2e60ad0e51 added a new check to the XML validation logic where XMLs containing <memoryBacking><mlocked/> must also contain <memtune><hard_limit>. This causes two breakages where working guests won't start anymore: 1. Systems where mlock limit was set in /etc/security/limits.conf 2. Guests using hugeTLB pages. In this case, guests were relying on the fact that libvirt automagically increases mlock limit to 1GB While it's true that <memoryBacking><mlocked/> documentation says that <memtune><hard_limit> is required, this is actually an extremely bad request because: A. <memtune><hard_limit> own documention strongly recommends NOT using it B. <memtune><hard_limit> does more than setting memory locking limit C. <memtune><hard_limit> does not support infinity, so you have to guess a limit D. If <memtune><hard_limit> is less than 1GB, it will lower VFIO's automatic limit of "guest memory + 1GB" Here's two possible solutions to fix this all: 1. Drop change c2e60ad0e51 and drop automatic increases. Let users configure limits in /etc/security/limits.conf pros: this is the most correct way to do it, and how it should be done originally IMHO cons: will break working VFIO setups, so probably undoable 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 Lastly, <locked/> doesn't belong to <memoryBacking>, it should be in <memtune>. I recommend deprecating it from <memoryBacking> and adding it where it belongs.