On 08/20/2013 11:10 AM, Michal Privoznik wrote:
> Since 16bcb3 we have a regression. The hard_limit is set
> unconditionally. By default, the limit is zero. Hence, if user hasn't
> configured any, we set the zero in cgroup subsystem making the kernel
> kill the corresponding qemu process immediately. The proper fix is to
> set hard_limit iff user has configure any.
> ---
> src/qemu/qemu_cgroup.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c
> index 9673e8e..e27945e 100644
> --- a/src/qemu/qemu_cgroup.c
> +++ b/src/qemu/qemu_cgroup.c
> @@ -428,7 +428,8 @@ qemuSetupMemoryCgroup(virDomainObjPtr vm)
> }
> }
>
> - if (virCgroupSetMemoryHardLimit(priv->cgroup, vm->def->mem.hard_limit)
< 0)
> + if (vm->def->mem.hard_limit != 0 &&
> + virCgroupSetMemoryHardLimit(priv->cgroup, vm->def->mem.hard_limit)
< 0)
> return -1;
>
> if (vm->def->mem.soft_limit != 0 &&
>
This still calls SetMaxMemLock with 0 if mem.hard_limit is 0. According to
commit 9395894 [1], it seems this won't be enough for VFIO passthrough
(although I haven't tested it). (Commit 6d8ebc7 [2] changed this to use
qemuDomainMemoryLimit)
Jan
[1]
http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=9395894
[2]
http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=6d8ebc7
I've posted a separate patch for that. So if you agree, can I push this one?
Michal