According to QEMU's nvdimm documentation: When 'pmem' is 'on' and QEMU is
built with libpmem support, QEMU will take necessary operations to guarantee
the persistence of its own writes to the vNVDIMM backend.
Signed-off-by: Julio Montes <julio.montes@intel.com>
Currently, virtio transports for each device are determined with
architecture dependent build time conditionals. This isn't the ideal
solution, as virtio transports aren't exactly tied to the host's
architecture.
For example, aarch64 VMs do support both PCI and MMIO devices, and
after the recent introduction of the microvm machine type, that's also
the case for x86_64.
This patch extends each device that supports multiple transports with
a VirtioTransport field, so users of the library can manually specify
a transport for each device. To avoid breaking the compatibility, if
VirtioTransport is empty a behavior equivalent to the legacy one is
achieved by checking runtime.GOARCH and Config.Machine.Type.
Keeping support for isVirtioPCI/isVirtioCCW in qmp.go is a bit
tricky. Eventually, the hot-plug API should be extended so callers
must manually specify the transport for the device.
Signed-off-by: Sergio Lopez <slp@redhat.com>
As there's no guarantee that ".cache-size" is a supported QEMU property,
let's not add it to the QEMU command line when the user explicitly set
virtio_fs_cache_size to zero.
By not always setting ".cache-size" property we avoid errors like:
```
$ sudo podman --runtime=/usr/bin/kata-runtime run --security-opt label=disable -it fedora:31 /bin/bash
Error: failed to launch qemu: exit status 1, error messages from qemu log: qemu-kvm: -device vhost-user-fs-pci,chardev=char-88c350403e95d3db,tag=kataShared,cache-size=0M: Property '.cache-size' not found: OCI runtime error
```
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Caller can hotplug vhost-user device via qmp.
The Qemu vhost-user device, like vhost-user-blk-pci and
vhost-user-scsi-pci can be hotplugged by qmp API:
ExecuteCharDevUnixSocketAdd() together with
ExecutePCIVhostUserDevAdd()
Signed-off-by: Liu Xiaodong <xiaodong.liu@intel.com>
Memory preallocation is just a property of different memory backends.
We should treat it similar to memory sharing property. Also rename
FileBackedMemShared to MemShared as it is just another memory backend
property that works with different memory backends not just file backed
memory.
Signed-off-by: Peng Tao <bergwolf@hyper.sh>
The upper hyervisor manager application maybe need to wait some
QMP event to control boot sequence, but the event we wanted maybe
not exist in some older version, so we need query all QMP ABI and
check the event is supported or not.
related: kata-containers/runtime#1918
Signed-off-by: Ning Bo <ning.bo9@zte.com.cn>
Support for function isSocketIDSupported, isThreadIDSupported and isDieIDSupported.
The functions check if the cpu driver and the qemu version support the
id parameter.
Fixes: #102
Signed-off-by: Alice Frosi <afrosi@de.ibm.com>
In QEMU 4.1 the CPU topology for x86 will change to:
`socket > die > core > thread`.
Add `die-id` field to `CPUProperties` and include it in CPU hotplugging
Signed-off-by: Julio Montes <julio.montes@intel.com>
since some vendor id like 1ded can not be identified by virtio-pci
driver, so upper level need to pass a specified vendor id to qemu.
the upper level will change unavailable id and pass it to qemu.
Signed-off-by: Ace-Tang <aceapril@126.com>
Hotplugged memory could be backed by a file on the host with sharing
turned on. This change allows qmp to pass that option to a govmm.
Signed-off-by: Ganesh Maharaj Mahalingam <ganesh.mahalingam@intel.com>
QEMU supports finer-grained units than GiB. Change the cache size to
MiB so users have more control over the cache size.
Note that changing the semantics of the CacheSize field is fine because
there are no users of this API yet. kata-runtime will be the first
users and prefers MiB instead of GiB.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
In newer versions of QEMU, like 4.0-rc2, QMP events can be thrown even before
the QMP-version response, one example of this behaviour is when a virtio serial
is closed and a VSERPORT_CHANGE event is thrown.
Re-implement mainLoop to check the data received from the VM channel, since
it's not a guarantee that the first data read from the VM channel is the
QMP version.
fixes https://github.com/kata-containers/runtime/issues/1474
Signed-off-by: Julio Montes <julio.montes@intel.com>
