[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [BUG?] limit too low in privcmd-buf.c



On 22.07.19 23:37, Andrew Cooper wrote:
On 22/07/2019 22:21, Stefano Stabellini wrote:
Hi Juergen,

We are working on a technology to limit cache interference between
guests running on the same SoC. It works well, but as a consequence, all
memory allocations are 4K only: higher granularities (2M, 1G) do not
work at all.

One of the issues I am seeing after upgrading dom0 kernel is that the
limit in privcmd-buf.c, which is 64, is too low.  (Previously I was
using an old kernel without privcmd-buf.c.) The issue is that I cannot
start a guest of 128MB because mmap returns an error, specifically the
following check in privcmd_buf_mmap:privcmd_buf_mmap fails:

         if (!(vma->vm_flags & VM_SHARED) || count > limit ||
             file_priv->allocated + count > limit)
             return -EINVAL;

The check to fail is "file_priv->allocated + count > limit".

In my tests, limit needs to be roughly similar to the amount of MB of
guest RAM given to the guest. For example, we want a limit of 512 to be
able to start a guest with 512MB of RAM.

For the moment, I solved the problem simply by increasing the limit.
However, I don't know for sure what the right limit would be and whether
it is the right way to solve the problem.

Do you have any suggestions?

That limit was removed shortly afterwards (it regressed migrating of
medium sized VMs), and really ought to have hit stable by now...

It was in 4.20 and 4.18 and 4.19 stable kernels have it. Pre-4.18 kernel
doesn't have privcmd-buf.c.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.