On Tue, Jul 23, 2019 at 10:08:55AM -0400, Vivek Goyal wrote:
> On Tue, Jul 23, 2019 at 02:32:27PM +0100, Stefan Hajnoczi wrote:
> > On Wed, Jul 17, 2019 at 08:42:58AM -0400, Vivek Goyal wrote:
> > > On Thu, Jun 27, 2019 at 10:09:16AM -0400, Michael S. Tsirkin wrote:
> > >
> > > [..]
> > > > Well it allocates resources on the host. If you don't
> > > > contain qemu then even just allocating virtual memory
> > > > can make host swap, right? If you contain it then
> > > > qemu will get killed instead but then you need to tell
> > > > guest what not to do so as not to get qemu killed.
> > >
> > > How is it different than running a malicious unpriviliged process on host?
> > >
> > > Denial of service should be mitigated by per process resource limits which
> > > will be true in this case as well.
> > >
> > > I am not sure I understand the concern here.
> >
> > There is a practical problem that the QEMU process may hit the mmap
> > limit and be unable to perform its own mmaps due to the DAX Window. A
> > limit must be enforced on the host so that QEMU's internal mmaps
> > succeed.
>
> But number of mmaps are already limited by dax window size which is
> controlled by virtiofsd. So all user has to do is start with smaller
> dax window size if this ever becomes a concern.
Yes, the DAX Window size sets a hard limit on the number of mappings
(window_size / page_size). I think we should still communicate a
maximum number of mappings to provide more control for cases where the
page size and DAX Window size don't produce a desirable number.
Consider that window_size = 8 GB and page_size = 4 KB already yields
2,097,152 maximum mappings. Oops, that number is too large!
Stefan
