On 11/15/2018 12:55 PM, marcandre.lureau@xxxxxxxxxx wrote: > From: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx> > > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
