[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |