Hi On Thu, Nov 15, 2018 at 5:56 PM Michal Privoznik <mprivozn@xxxxxxxxxx> wrote: > > 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 Ok Thank you Michal! -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
