On Thu, Jun 22, 2017 at 11:58:14AM +0200, David Hildenbrand wrote:
> On 21.06.2017 16:02, Marc-André Lureau wrote:
> > Add a new Linux-specific memory backend, similar to hostmem-file,
> > except that it doesn't need file path. It also try to enforce memory
> > sealing if available. It is thus slightly easier and secure, and is
> > compatible with transparent huge-pages since Linux 4.8.
> >
> > v4:
> > - rebased, now that preliminary patches are merged
> >
> > v3:
> > - make vhost-user-test use memfd only if possible
> > - rebased
> >
> > v1->v2:
> > - make it linux-specific
> > - minor changes and commit message tweaks
> >
> > Marc-André Lureau (3):
> > memfd: split qemu_memfd_alloc()
> > Add memfd based hostmem
> > tests: use memfd in vhost-user-test
> >
> > include/qemu/memfd.h | 2 ++
> > backends/hostmem-memfd.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++
> > tests/vhost-user-test.c | 68 +++++++++++++++++++++++++++++++-----------------
> > util/memfd.c | 42 ++++++++++++++++++------------
> > backends/Makefile.objs | 2 ++
> > qemu-options.hx | 11 ++++++++
> > 6 files changed, 151 insertions(+), 41 deletions(-)
> > create mode 100644 backends/hostmem-memfd.c
> >
>
> Just wondering if it would make more sense to add a new parameter to the
> ram backend. Sorry if this has already been discussed.
That was my first thought, too. But although it requires more
boilerplate code, a separate class gives us better input
specification/validation for free: e.g. if we add memfd-specific options
in the future, we don't even need to document them as "valid only in
memfd mode", because they will exist only in the memfd class.
--
Eduardo