Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging

F: contrib/vhost-user-input/*

virtio-serial

M: Amit Shah <amit@kernel.org>

M: Laurent Vivier <lvivier@redhat.com>

R: Amit Shah <amit@kernel.org>

S: Supported

F: hw/char/virtio-serial-bus.c

F: hw/char/virtio-console.c

F: tests/virtio-serial-test.c

virtio-rng

M: Amit Shah <amit@kernel.org>

M: Laurent Vivier <lvivier@redhat.com>

R: Amit Shah <amit@kernel.org>

S: Supported

F: hw/virtio/virtio-rng.c

F: include/hw/virtio/virtio-rng.h

    b->vdev = vdev;

    b->dev.nvqs = nvqs;

    b->dev.vqs = g_new(struct vhost_virtqueue, nvqs);

    b->dev.vqs = g_new0(struct vhost_virtqueue, nvqs);

    ret = vhost_dev_init(&b->dev, &b->vhost_user, VHOST_BACKEND_TYPE_USER, 0);

    if (ret < 0) {

accept persistent writes. In result, for example, the guest Linux

NVDIMM driver, marks such vNVDIMM device as read-only.

Backend File Setup Example

--------------------------

Here are two examples showing how to setup these persistent backends on

linux using the tool ndctl [3].

A. DAX device

Use the following command to set up /dev/dax0.0 so that the entirety of

namespace0.0 can be exposed as an emulated NVDIMM to the guest:

    ndctl create-namespace -f -e namespace0.0 -m devdax

The /dev/dax0.0 could be used directly in "mem-path" option.

B. DAX file

Individual files on a DAX host file system can be exposed as emulated

NVDIMMS.  First an fsdax block device is created, partitioned, and then

mounted with the "dax" mount option:

    ndctl create-namespace -f -e namespace0.0 -m fsdax

    (partition /dev/pmem0 with name pmem0p1)

    mount -o dax /dev/pmem0p1 /mnt

    (create or copy a disk image file with qemu-img(1), cp(1), or dd(1)

     in /mnt)

Then the new file in /mnt could be used in "mem-path" option.

NVDIMM Persistence

------------------

    https://www.snia.org/sites/default/files/technical_work/final/NVMProgrammingModel_v1.2.pdf

[2] Persistent Memory Development Kit (PMDK), formerly known as NVML project, home page:

    http://pmem.io/pmdk/

[3] ndctl-create-namespace - provision or reconfigure a namespace

    http://pmem.io/ndctl/ndctl-create-namespace.html

========================

QEMU virtio pmem

========================

 This document explains the setup and usage of the virtio pmem device

 which is available since QEMU v4.1.0.

 The virtio pmem device is a paravirtualized persistent memory device

 on regular (i.e non-NVDIMM) storage.

Usecase

--------

  Virtio pmem allows to bypass the guest page cache and directly use

  host page cache. This reduces guest memory footprint as the host can

  make efficient memory reclaim decisions under memory pressure.

o How does virtio-pmem compare to the nvdimm emulation supported by QEMU?

  NVDIMM emulation on regular (i.e. non-NVDIMM) host storage does not

  persist the guest writes as there are no defined semantics in the device

  specification. The virtio pmem device provides guest write persistence

  on non-NVDIMM host storage.

virtio pmem usage

-----------------

  A virtio pmem device backed by a memory-backend-file can be created on

  the QEMU command line as in the following example:

  -object memory-backend-file,id=mem1,share,mem-path=./virtio_pmem.img,size=4G

  -device virtio-pmem-pci,memdev=mem1,id=nv1

   where:

   - "object memory-backend-file,id=mem1,share,mem-path=<image>, size=<image size>"

     creates a backend file with the specified size.

   - "device virtio-pmem-pci,id=nvdimm1,memdev=mem1" creates a virtio pmem

     pci device whose storage is provided by above memory backend device.

  Multiple virtio pmem devices can be created if multiple pairs of "-object"

  and "-device" are provided.

Hotplug

-------

Virtio pmem devices can be hotplugged via the QEMU monitor. First, the

memory backing has to be added via 'object_add'; afterwards, the virtio

pmem device can be added via 'device_add'.

For example, the following commands add another 4GB virtio pmem device to

the guest:

 (qemu) object_add memory-backend-file,id=mem2,share=on,mem-path=virtio_pmem2.img,size=4G

 (qemu) device_add virtio-pmem-pci,id=virtio_pmem2,memdev=mem2

Guest Data Persistence

----------------------

 Guest data persistence on non-NVDIMM requires guest userspace applications

 to perform fsync/msync. This is different from a real nvdimm backend where

 no additional fsync/msync is required. This is to persist guest writes in

 host backing file which otherwise remains in host page cache and there is

 risk of losing the data in case of power failure.

 With virtio pmem device, MAP_SYNC mmap flag is not supported. This provides

 a hint to application to perform fsync for write persistence.

Limitations

------------

- Real nvdimm device backend is not supported.

- virtio pmem hotunplug is not supported.

- ACPI NVDIMM features like regions/namespaces are not supported.

- ndctl command is not supported.

    }

    s->inflight = g_new0(struct vhost_inflight, 1);

    s->vqs = g_new(struct vhost_virtqueue, s->num_queues);

    s->vqs = g_new0(struct vhost_virtqueue, s->num_queues);

    s->watch = 0;

    s->connected = false;