[libvirt] [PATCH v3 0/3] Add "memfd" memory backing type (resend)

[Michal Privoznik]

On 11/15/2018 12:55 PM, marcandre.lureau at redhat.com wrote:
> From: Marc-André Lureau <marcandre.lureau at redhat.com>
> 
> Hi,
> 
> This is an alternative series from "[PATCH 0/5] Use memfd if
> possible". Instead of automatically using memfd for anonymous memory
> when available (as suggested by Daniel), it introduces the "memfd"
> memory backing type.
> 
> Although using memfd transparently when possible is a good idea, it is
> a source of various complications for migration & save/restore. This
> could eventually be challenged in a different series.
> 
> *please*:
> The first two patches have been modified and reviewed by John
> Ferlan. Hopefully they can be merged early, regardless of the last
> patch outcome, to avoid the painful rebase conflicts due to
> capabilities checks introduction.
> 
> Thanks :)
> 
> v3:
>  - rebased, to fix capabilities check and ping the series
> 
> Marc-André Lureau (3):
>   qemu: add memory-backend-memfd capability check
>   qemu: check memory-backend-memfd.hugetlb capability
>   qemu: add memfd source type
> 
>  docs/formatdomain.html.in                     |   9 +-
>  docs/schemas/domaincommon.rng                 |   1 +
>  src/conf/domain_conf.c                        |   3 +-
>  src/conf/domain_conf.h                        |   1 +
>  src/qemu/qemu_capabilities.c                  |  10 ++
>  src/qemu/qemu_capabilities.h                  |   2 +
>  src/qemu/qemu_command.c                       |  69 +++++++----
>  src/qemu/qemu_domain.c                        |  12 +-
>  .../caps_2.12.0.aarch64.replies               |  94 ++++++++++++---
>  .../caps_2.12.0.aarch64.xml                   |   4 +-
>  .../caps_2.12.0.ppc64.replies                 |  90 +++++++++++---
>  .../caps_2.12.0.ppc64.xml                     |   4 +-
>  .../caps_2.12.0.s390x.replies                 |  98 ++++++++++++----
>  .../caps_2.12.0.s390x.xml                     |   4 +-
>  .../caps_2.12.0.x86_64.replies                | 110 +++++++++++++-----
>  .../caps_2.12.0.x86_64.xml                    |   4 +-
>  .../caps_3.0.0.ppc64.replies                  |  90 +++++++++++---
>  .../qemucapabilitiesdata/caps_3.0.0.ppc64.xml |   4 +-
>  .../caps_3.0.0.riscv32.replies                |  86 +++++++++++---
>  .../caps_3.0.0.riscv32.xml                    |   2 +
>  .../caps_3.0.0.riscv64.replies                |  86 +++++++++++---
>  .../caps_3.0.0.riscv64.xml                    |   2 +
>  .../caps_3.0.0.s390x.replies                  |  98 ++++++++++++----
>  .../qemucapabilitiesdata/caps_3.0.0.s390x.xml |   4 +-
>  .../caps_3.0.0.x86_64.replies                 | 110 +++++++++++++-----
>  .../caps_3.0.0.x86_64.xml                     |   4 +-
>  .../memfd-memory-numa.x86_64-latest.args      |  34 ++++++
>  tests/qemuxml2argvdata/memfd-memory-numa.xml  |  36 ++++++
>  tests/qemuxml2argvtest.c                      |   2 +
>  29 files changed, 869 insertions(+), 204 deletions(-)
>  create mode 100644 tests/qemuxml2argvdata/memfd-memory-numa.x86_64-latest.args
>  create mode 100644 tests/qemuxml2argvdata/memfd-memory-numa.xml
> 

I've did the review and all three patches look good to me. I've fixed
all the issues I've found and I'm keeping them in a local branch of mine
to give others some time to raise their concerns should they have some.

My main concern was that we would be exposing memory backend to users by
giving them a config knob that could be set to enforce memfd usage. But
I don't think there is any other way, esp. since memory backends are not
real backends (one can't migrate a domain that was started with one to
another one).

ACK series

Michal