[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]