master
rst 126 lines 3.7 KB
Raw
1 vhost-user daemons in contrib
2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3
4 QEMU provides a number of :ref:`vhost_user` daemons in the contrib
5 directory. They were often written when vhost-user was initially added
6 to the code base. You should also consider if other vhost-user daemons
7 such as those from the rust-vmm `vhost-device repository`_ are better
8 suited for production use.
9
10 .. _vhost-device repository: https://github.com/rust-vmm/vhost-device
11
12 .. _vhost_user_block:
13
14 vhost-user-block - block device
15 ===============================
16
17 vhost-user-block is a backend for exposing block devices. It can
18 present a flat file or block device as a simple block device to the
19 guest. You almost certainly want to use the :ref:`storage-daemon`
20 instead which supports a wide variety of storage modes and exports a
21 number of interfaces including vhost-user.
22
23 .. _vhost_user_gpu:
24
25 vhost-user-gpu - gpu device
26 ===========================
27
28 vhost-user-gpu presents a paravirtualized GPU and display controller.
29 You probably want to use the internal :ref:`virtio_gpu` implementation
30 if you want the latest features. There is also a `vhost_device_gpu`_
31 daemon as part of the rust-vmm project.
32
33 .. _vhost_device_gpu: https://github.com/rust-vmm/vhost-device/tree/main/vhost-device-gpu
34
35 .. _vhost_user_input:
36
37 vhost-user-input - Input emulation
38 ==================================
39
40 The Virtio input device is a paravirtualized device for input events.
41
42 Description
43 -----------
44
45 The vhost-user-input device implementation was designed to work with a daemon
46 polling on input devices and passes input events to the guest.
47
48 QEMU provides a backend implementation in contrib/vhost-user-input.
49
50 Linux kernel support
51 --------------------
52
53 Virtio input requires a guest Linux kernel built with the
54 ``CONFIG_VIRTIO_INPUT`` option.
55
56 Examples
57 --------
58
59 The backend daemon should be started first:
60
61 ::
62
63 host# vhost-user-input --socket-path=input.sock \
64 --evdev-path=/dev/input/event17
65
66 The QEMU invocation needs to create a chardev socket to communicate with the
67 backend daemon and access the VirtIO queues with the guest over the
68 :ref:`shared memory <shared_memory_object>`.
69
70 ::
71
72 host# qemu-system \
73 -chardev socket,path=/tmp/input.sock,id=mouse0 \
74 -device vhost-user-input-pci,chardev=mouse0 \
75 -m 4096 \
76 -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on \
77 -numa node,memdev=mem \
78 ...
79
80
81 .. _vhost_user_scsi:
82
83 vhost-user-scsi - SCSI controller
84 =================================
85
86 The vhost-user-scsi daemon can proxy iSCSI devices onto a virtualized
87 SCSI controller.
88
89 .. _vhost_user_bridge:
90
91 vhost-user-bridge - Network bridge
92 ==================================
93
94 The vhost-user-bridge daemon serves as a development tool for testing real
95 internet traffic by providing a networking backend, i.e. server, for the
96 vhost-user protocol.
97
98 Example
99 -------
100 For a single QEMU instance that both runs the user-mode net stack (slirp) and
101 serves as a vhost-user protocol frontend, i.e. client, simultaneously:
102
103 First, start vhost-user-bridge:
104
105 ::
106
107 $ vhost-user-bridge -u /tmp/vubr.sock \
108 -l 127.0.0.1:4444 \
109 -r 127.0.0.1:5555
110
111 Then, invoke QEMU:
112
113 ::
114
115 $ qemu-system-x86_64 \
116 -m 4G \
117 -object memory-backend-memfd,id=mem0,size=4G,share=on,prealloc=on \
118 -numa node,memdev=mem0 \
119 -chardev socket,id=char0,path=/tmp/vubr.sock \
120 -netdev vhost-user,id=vhost0,chardev=char0,vhostforce=on \
121 -device virtio-net-pci,netdev=vhost0 \
122 -netdev socket,id=udp0,udp=localhost:4444,localaddr=localhost:5555 \
123 -netdev user,id=user0 \
124 -netdev hubport,id=hub0,hubid=0,netdev=udp0 \
125 -netdev hubport,id=hub1,hubid=0,netdev=user0 \
126 ...