[libvirt] [PATCH 8/8] qemu: set qemu process' RLIMIT_MEMLOCK when VFIO is used

[Laine Stump]

On 04/25/2013 06:14 PM, Eric Blake wrote:
> On 04/25/2013 11:57 AM, Laine Stump wrote:
>> VFIO requires all of the guest's memory and IO space to be lockable in
>> RAM. The domain's max_balloon is the maximum amount of memory the
>> domain can have (in KiB). We add a generous 1GiB to that for IO space
>> (still much better than KVM device assignment, where the KVM module
>> actually *ignores* the process limits and locks everything anyway),
>> and convert from KiB to bytes.
>>
>> In the case of hotplug, we are changing the limit for the already
>> existing qemu process (prlimit() is used under the hood), and for
>> regular commandline additions of vfio devices, we schedule a call to
>> setrlimit() that will happen after the qemu process is forked.
>> ---
>>  src/qemu/qemu_command.c | 22 +++++++++++++++-------
>>  src/qemu/qemu_hotplug.c | 24 +++++++++++++++++-------
>>  2 files changed, 32 insertions(+), 14 deletions(-)
>>
>> +                /* VFIO requires all of the guest's memory to be
>> +                 * locked resident, plus some amount for IO
>> +                 * space. Alex Williamson suggested adding 1GiB for IO
>> +                 * space just to be safe (some finer tuning might be
>> +                 * nice, though).
>> +                 */
>> +                virCommandSetMaxMemLock(cmd, ((unsigned long long)def->mem.max_balloon + (1024 * 1024)) * 1024);
> Worth wrapping the long line, perhaps at the + operator?  Or even using
> a temporary:
> unsigned long long mem_kbytes = def->mem.max_balloon + (1024 * 1024);
> virCommandSetMaxMemLock(cmd, mem_kbytes * 1024);

I did the latter.


>
>> +        virSetMaxMemLock(vm->pid,
>> +                         ((unsigned long long)vm->def->mem.max_balloon + (1024 * 1024)) * 1024);
> and again.


Same here.


>   Line wrapping is trivial, though, so:
>
> ACK.
>