[libvirt] [PATCH 2/5] qemu: check memory-backend-memfd.hugetlb capability

John Ferlan jferlan at redhat.com
Mon Sep 10 22:46:30 UTC 2018



On 09/07/2018 07:32 AM, marcandre.lureau at redhat.com wrote:
> From: Marc-André Lureau <marcandre.lureau at redhat.com>
> 
> QEMU 3.1 should only expose the property if the host is actually
> capable of creating hugetable-backed memfd. However, it may fail
> at runtime depending on requested "hugetlbsize".
> 
> Signed-off-by: Marc-André Lureau <marcandre.lureau at redhat.com>
> ---
>  src/qemu/qemu_capabilities.c                  |   8 ++
>  src/qemu/qemu_capabilities.h                  |   1 +
>  .../caps_2.12.0.aarch64.replies               |  94 ++++++++++++---
>  .../caps_2.12.0.aarch64.xml                   |   3 +-
>  .../caps_2.12.0.ppc64.replies                 |  90 +++++++++++---
>  .../caps_2.12.0.ppc64.xml                     |   3 +-
>  .../caps_2.12.0.s390x.replies                 |  98 ++++++++++++----
>  .../caps_2.12.0.s390x.xml                     |   3 +-
>  .../caps_2.12.0.x86_64.replies                | 110 +++++++++++++-----
>  .../caps_2.12.0.x86_64.xml                    |   3 +-
>  .../caps_3.0.0.ppc64.replies                  |  90 +++++++++++---
>  .../qemucapabilitiesdata/caps_3.0.0.ppc64.xml |   3 +-
>  .../caps_3.0.0.riscv32.replies                |  86 +++++++++++---
>  .../caps_3.0.0.riscv32.xml                    |   1 +
>  .../caps_3.0.0.riscv64.replies                |  86 +++++++++++---
>  .../caps_3.0.0.riscv64.xml                    |   1 +
>  .../caps_3.0.0.x86_64.replies                 | 110 +++++++++++++-----
>  .../caps_3.0.0.x86_64.xml                     |   3 +-
>  18 files changed, 637 insertions(+), 156 deletions(-)

This one ended up being more ugly because Jano posted, got ACK'd, and
pushed a series that removed some capabilities and adjusted the
*.replies numbering. I was able to merge with some amount of effort.

Some grumble, mumble about it being easier when there's a qapi/*.json
file that lists the command and argument options as opposed to looking
through source code ;-)

Reviewed-by: John Ferlan <jferlan at redhat.com>

John




More information about the libvir-list mailing list