Re: [Qemu-devel] [PATCH 3/3] balloon: don't use NVDIMM for ballooning

[Markus Armbruster <armbru@redhat.com>]

Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> writes:

> NVDIMM for now is planned to use as a backing store for DAX filesystem
> in the guest and thus this memory is excluded from guest memory
> management and LRUs.
>
> In this case libvirt running QEMU along with configured balloon almost
> immediately inflates balloon and effectively kill the guest as
> qemu counts nvdimm as part of the ram.
>
> Counting dimm devices as part of the ram for ballooning was started from
> commit 463756d03:
>  virtio-balloon: Fix balloon not working correctly when hotplug memory
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> CC: Stefan Hajnoczi <stefanha@redhat.com>
> CC: Xiao Guangrong <guangrong.xiao@linux.intel.com>
> CC: "Michael S. Tsirkin" <mst@redhat.com>
> CC: Igor Mammedov <imammedo@redhat.com>
> CC: Eric Blake <eblake@redhat.com>
> CC: Markus Armbruster <armbru@redhat.com>
> ---
>  hw/virtio/virtio-balloon.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> index 6a4c4d2..749be25 100644
> --- a/hw/virtio/virtio-balloon.c
> +++ b/hw/virtio/virtio-balloon.c
> @@ -26,6 +26,7 @@
>  #include "qapi/visitor.h"
>  #include "qapi-event.h"
>  #include "trace.h"
> +#include "hw/mem/nvdimm.h"
>  
>  #if defined(__linux__)
>  #include <sys/mman.h>
> @@ -308,7 +309,9 @@ static ram_addr_t get_current_ram_size(void)
>          if (value) {
>              switch (value->type) {
>              case MEMORY_DEVICE_INFO_KIND_DIMM:
> -                size += value->u.dimm->size;
> +                if (strcmp(value->u.dimm->type, TYPE_NVDIMM)) {
> +                    size += value->u.dimm->size;
> +                }
>                  break;
>              default:
>                  break;

Should this be a blacklist ("don't count TYPE_NVDIMM") or a whitelist
("count TYPE_PC_DIMM")?  I guess that depends on whether we think future
types are more likely to need counting or not counting.