Hi
On Thu, Nov 15, 2018 at 5:56 PM Michal Privoznik <mprivozn@redhat.com> wrote:
>
> On 11/15/2018 12:55 PM, marcandre.lureau@redhat.com wrote:
> > From: Marc-André Lureau <marcandre.lureau@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
Ok
Thank you Michal!
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list