virtio,pc,pci: features, cleanups, fixes

vhost-user-snd support
 x2APIC mode with TCG support
 CXL update to r3.1
 
 fixes, cleanups all over the place.
 
 Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
 -----BEGIN PGP SIGNATURE-----
 
 iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmXMoXUPHG1zdEByZWRo
 YXQuY29tAAoJECgfDbjSjVRpFtMIAKUKD0hzJrwOyPo4xsRUMbsB3ehIsJsMKfOK
 w+JWzTaojAG8ENPelWBdL2sEIs5U73VOchjLqHbH2m5sz6GJ13214amvdU/fYc8+
 /dU2ZKoAmaR5L1ovKO/fq07y/J6DrITZ5tosy2i84Xa8EnsL4j3wEPNVWsDi7dna
 mvXUICSOOoJQ4O2YhSruKCQ8qIgF1/0Oi3u/rcrW3alSs8VQlrtQXxl6k+LbYqek
 +Fytco3jMRHPvQ+GYUIwGuHjN15ghArcvbsV0GIa+24BPY5h7YbDYGbfasePT5OK
 zDz51jitkoyDrQr+OzwOEe/X5+dVGhayRXfMtU5Qm53IE3y61qc=
 =K4b1
 -----END PGP SIGNATURE-----

Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu into staging

virtio,pc,pci: features, cleanups, fixes

vhost-user-snd support
x2APIC mode with TCG support
CXL update to r3.1

fixes, cleanups all over the place.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

# -----BEGIN PGP SIGNATURE-----
#
# iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmXMoXUPHG1zdEByZWRo
# YXQuY29tAAoJECgfDbjSjVRpFtMIAKUKD0hzJrwOyPo4xsRUMbsB3ehIsJsMKfOK
# w+JWzTaojAG8ENPelWBdL2sEIs5U73VOchjLqHbH2m5sz6GJ13214amvdU/fYc8+
# /dU2ZKoAmaR5L1ovKO/fq07y/J6DrITZ5tosy2i84Xa8EnsL4j3wEPNVWsDi7dna
# mvXUICSOOoJQ4O2YhSruKCQ8qIgF1/0Oi3u/rcrW3alSs8VQlrtQXxl6k+LbYqek
# +Fytco3jMRHPvQ+GYUIwGuHjN15ghArcvbsV0GIa+24BPY5h7YbDYGbfasePT5OK
# zDz51jitkoyDrQr+OzwOEe/X5+dVGhayRXfMtU5Qm53IE3y61qc=
# =K4b1
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 14 Feb 2024 11:18:13 GMT
# gpg:                using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469
# gpg:                issuer "mst@redhat.com"
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full]
# gpg:                 aka "Michael S. Tsirkin <mst@redhat.com>" [full]
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17  0970 C350 3912 AFBE 8E67
#      Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA  8A0D 281F 0DB8 D28D 5469

* tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (60 commits)
  MAINTAINERS: Switch to my Enfabrica email
  virtio-gpu-rutabaga.c: override resource_destroy method
  virtio-gpu.c: add resource_destroy class method
  hw/display/virtio-gpu.c: use reset_bh class method
  hw/smbios: Fix port connector option validation
  hw/smbios: Fix OEM strings table option validation
  virtio-gpu: Correct virgl_renderer_resource_get_info() error check
  hw/cxl: Standardize all references on CXL r3.1 and minor updates
  hw/cxl: Update mailbox status registers.
  hw/cxl: Update RAS Capability Definitions for version 3.
  hw/cxl: Update link register definitions.
  hw/cxl: Update HDM Decoder capability to version 3
  tests/acpi: Update DSDT.cxl to reflect change _STA return value.
  hw/i386: Fix _STA return value for ACPI0017
  tests/acpi: Allow update of DSDT.cxl
  hw/mem/cxl_type3: Fix potential divide by zero reported by coverity
  hw/cxl: Pass NULL for a NULL MemoryRegionOps
  hw/cxl: Pass CXLComponentState to cache_mem_ops
  hw/cxl/device: read from register values in mdev_reg_read()
  hw/cxl/mbox: Remove dead code
  ...

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This commit is contained in:
Peter Maydell 2024-02-14 15:45:52 +00:00
commit 5767815218
84 changed files with 2004 additions and 1910 deletions

View file

@ -431,10 +431,10 @@ data doesn't match the stored device data well; it allows an
intermediate temporary structure to be populated with migration
data and then transferred to the main structure.
If you use memory API functions that update memory layout outside
If you use memory or portio_list API functions that update memory layout outside
initialization (i.e., in response to a guest action), this is a strong
indication that you need to call these functions in a ``post_load`` callback.
Examples of such memory API functions are:
Examples of such API functions are:
- memory_region_add_subregion()
- memory_region_del_subregion()
@ -443,6 +443,8 @@ Examples of such memory API functions are:
- memory_region_set_enabled()
- memory_region_set_address()
- memory_region_set_alias_offset()
- portio_list_set_address()
- portio_list_set_enabled()
Iterative device migration
--------------------------

View file

@ -148,9 +148,9 @@ Vring descriptor indices for packed virtqueues
A vring address description
^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-------+-------+------+------------+------+-----------+-----+
| index | flags | size | descriptor | used | available | log |
+-------+-------+------+------------+------+-----------+-----+
+-------+-------+------------+------+-----------+-----+
| index | flags | descriptor | used | available | log |
+-------+-------+------------+------+-----------+-----+
:index: a 32-bit vring index

View file

@ -94,6 +94,7 @@ Emulated Devices
devices/virtio-gpu.rst
devices/virtio-pmem.rst
devices/virtio-snd.rst
devices/vhost-user-input.rst
devices/vhost-user-rng.rst
devices/canokey.rst
devices/usb-u2f.rst

View file

@ -411,5 +411,4 @@ References
- Consortium website for specifications etc:
http://www.computeexpresslink.org
- Compute Express link Revision 2 specification, October 2020
- CEDT CFMWS & QTG _DSM ECN May 2021
- Compute Express Link (CXL) Specification, Revision 3.1, August 2023

View file

@ -0,0 +1,45 @@
.. _vhost_user_input:
QEMU vhost-user-input - Input emulation
=======================================
This document describes the setup and usage of the Virtio input device.
The Virtio input device is a paravirtualized device for input events.
Description
-----------
The vhost-user-input device implementation was designed to work with a daemon
polling on input devices and passes input events to the guest.
QEMU provides a backend implementation in contrib/vhost-user-input.
Linux kernel support
--------------------
Virtio input requires a guest Linux kernel built with the
``CONFIG_VIRTIO_INPUT`` option.
Examples
--------
The backend daemon should be started first:
::
host# vhost-user-input --socket-path=input.sock \
--evdev-path=/dev/input/event17
The QEMU invocation needs to create a chardev socket to communicate with the
backend daemon and access the VirtIO queues with the guest over the
:ref:`shared memory <shared_memory_object>`.
::
host# qemu-system \
-chardev socket,path=/tmp/input.sock,id=mouse0 \
-device vhost-user-input-pci,chardev=mouse0 \
-m 4096 \
-object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on \
-numa node,memdev=mem \
...

View file

@ -1,3 +1,5 @@
.. _vhost_user_rng:
QEMU vhost-user-rng - RNG emulation
===================================

View file

@ -8,13 +8,81 @@ outside of QEMU itself. To do this there are a number of things
required.
vhost-user device
===================
=================
These are simple stub devices that ensure the VirtIO device is visible
to the guest. The code is mostly boilerplate although each device has
a ``chardev`` option which specifies the ID of the ``--chardev``
device that connects via a socket to the vhost-user *daemon*.
Each device will have an virtio-mmio and virtio-pci variant. See your
platform details for what sort of virtio bus to use.
.. list-table:: vhost-user devices
:widths: 20 20 60
:header-rows: 1
* - Device
- Type
- Notes
* - vhost-user-blk
- Block storage
- See contrib/vhost-user-blk
* - vhost-user-fs
- File based storage driver
- See https://gitlab.com/virtio-fs/virtiofsd
* - vhost-user-gpio
- Proxy gpio pins to host
- See https://github.com/rust-vmm/vhost-device
* - vhost-user-gpu
- GPU driver
- See contrib/vhost-user-gpu
* - vhost-user-i2c
- Proxy i2c devices to host
- See https://github.com/rust-vmm/vhost-device
* - vhost-user-input
- Generic input driver
- :ref:`vhost_user_input`
* - vhost-user-rng
- Entropy driver
- :ref:`vhost_user_rng`
* - vhost-user-scmi
- System Control and Management Interface
- See https://github.com/rust-vmm/vhost-device
* - vhost-user-snd
- Audio device
- See https://github.com/rust-vmm/vhost-device/staging
* - vhost-user-scsi
- SCSI based storage
- See contrib/vhost-user-scsi
* - vhost-user-vsock
- Socket based communication
- See https://github.com/rust-vmm/vhost-device
The referenced *daemons* are not exhaustive, any conforming backend
implementing the device and using the vhost-user protocol should work.
vhost-user-device
^^^^^^^^^^^^^^^^^
The vhost-user-device is a generic development device intended for
expert use while developing new backends. The user needs to specify
all the required parameters including:
- Device ``virtio-id``
- The ``num_vqs`` it needs and their ``vq_size``
- The ``config_size`` if needed
.. note::
To prevent user confusion you cannot currently instantiate
vhost-user-device without first patching out::
/* Reason: stop inexperienced users confusing themselves */
dc->user_creatable = false;
in ``vhost-user-device.c`` and ``vhost-user-device-pci.c`` file and
rebuilding.
vhost-user daemon
=================
@ -23,6 +91,8 @@ following the :ref:`vhost_user_proto`. There are a number of daemons
that can be built when enabled by the project although any daemon that
meets the specification for a given device can be used.
.. _shared_memory_object:
Shared memory object
====================