OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-dev] [PATCH v3 2/2] virtio-fs: add DAX window


On Tue, Jul 23, 2019 at 11:56:23AM -0400, Vivek Goyal wrote:
> On Tue, Jul 23, 2019 at 03:52:50PM +0100, Stefan Hajnoczi wrote:
> > 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!
> 
> Ok, so that's something which will be in virtiofsd where maximum number
> of outstanding can be configured by user and if we cross that limit,
> FUSE_SETUPMAPPING will be returned with some error?

Yes, virtiofsd will enforce the limit.

The guest driver will also be aware of the limit via VIRTIO
configuration space.

Stefan

Attachment: signature.asc
Description: PGP signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]