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

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);

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

Line wrapping is trivial, though, so: ACK.