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

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

[Stefano Stabellini]

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?

Cheers,

Stefano

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

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

[Andrew Cooper]

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...

~Andrew

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

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

[Juergen Gross]

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel