hw/virtio/vhost.h

89     /* the first virtqueue which would be used by this vhost dev */
91     /* one past the last vq index for the virtio device (not vhost) */
96      * vhost feature handling requires matching the feature set
97      * offered by a backend which may be a subset of the total
98      * features eventually offered to the guest.
100      * @features: available features provided by the backend
106      * future use should be discouraged and the variable retired as
107      * its easy to confuse with the VirtIO backend_features.
114      * @protocol_features: is the vhost-user only feature set by
117      * by the backend (see @features).
123     /* @started: is the vhost device started? */
150  * vhost_dev_init() - initialise the vhost interface
151  * @hdev: the common vhost_dev structure
157  * The initialisation of the vhost device will trigger the
158  * initialisation of the backend and potentially capability
159  * negotiation of backend interface. Configuration of the VirtIO
160  * itself won't happen until the interface is started.
170  * @hdev: the common vhost_dev structure
181  * @vdev: the VirtIODevice structure
183  * Enable notifications directly to the vhost device rather than being
185  * the vhost device is started via @vhost_dev_start.
194  * @vdev: the VirtIODevice structure
206  * Return the started status of the vhost device
214  * vhost_dev_start() - start the vhost device
216  * @vdev: the VirtIODevice structure
219  * Starts the vhost device. From this point VirtIO feature negotiation
220  * can start and the device can start processing VirtIO transactions.
227  * vhost_dev_stop() - stop the vhost device
229  * @vdev: the VirtIODevice structure
232  * Stop the vhost device. After the device is stopped the notifiers
233  * can be disabled (@vhost_dev_disable_notifiers) and the device can
243  * The VirtIO device configuration space is used for rarely changing
244  * or initialisation time parameters. The configuration can be updated
245  * by either the guest driver or the device itself. If the device can
246  * change the configuration over time the vhost handler should
248  * @vhost_dev_set_config_notifier so the guest can be notified. Some
272  * By use of @offset/@size a subset of the configuration space can be
273  * written to. The @flags are used to indicate if it is a normal
286  * If the device is expected to change configuration a notifier can be
287  * setup to handle the case.
310  * is supported by the vhost backend (hdev->features), the supported
311  * feature_bits and the requested feature set.
322  * This sets the internal hdev->acked_features to the intersection of
323  * the backends advertised features and the supported feature_bits.
360  * vhost_supports_device_state(): Checks whether the back-end supports
361  * transferring internal device state for the purpose of migration.
365  * @dev: The vhost device
367  * Returns true if the device supports these commands, and false if it
381  * the back-end for the purpose of migration.  Data is to be transferred
382  * over a pipe according to @direction and @phase.  The sending end must
383  * only write to the pipe, and the receiving end must only read from it.
384  * Once the sending end is done, it closes its FD.  The receiving end
385  * must take this as the end-of-transfer signal and close its FD, too.
387  * @fd is the back-end's end of the pipe: The write FD for SAVE, and the
388  * read FD for LOAD.  This function transfers ownership of @fd to the
389  * back-end, i.e. closes it in the front-end.
391  * The back-end may optionally reply with an FD of its own, if this
392  * improves efficiency on its end.  In this case, the returned FD is
393  * stored in *reply_fd.  The back-end will discard the FD sent to it,
394  * and the front-end must use *reply_fd for transferring state to/from
395  * the back-end.
397  * @dev: The vhost device
398  * @direction: The direction in which the state is to be transferred.
400  *             from the back-end and stored by the front-end in the
403  *             by the front-end from the migration stream and sent to
404  *             the back-end to restore the saved state.
406  *         STOPPED (device and all vrings are stopped), in the future,
408  * @fd: Back-end's end of the pipe through which to transfer state; note
409  *      that ownership is transferred to the back-end, so this function
410  *      closes @fd in the front-end.
411  * @reply_fd: If the back-end wishes to use a different pipe for state
412  *            transfer, this will contain an FD for the front-end to
426  * vhost_set_device_state_fd(): After transferring state from/to the
427  * back-end via vhost_set_device_state_fd(), i.e. once the sending end
428  * has closed the pipe, inquire the back-end to report any potential
431  * - During outgoing migration, when the source side had already started
433  * - During incoming migration, when the received state is somehow
434  *   invalid and cannot be processed by the back-end
436  * @dev: The vhost device
439  * Returns 0 when the back-end reports successful state transfer and
447  * `vhost_set_device_state_fd()` to get the data from the back-end, and
449  * respective length (be32).  The end is marked by a 0-length chunk.
451  * Must only be called while the device and all its vrings are stopped
454  * @dev: The vhost device from which to save the state
455  * @f: Migration stream in which to save the state
472  * back-end's state from @f, and send it over to the back-end.  Reads
473  * the data from @f in the format used by `vhost_save_state()`, and uses
474  * `vhost_set_device_state_fd()` to transfer it to the back-end.
476  * Must only be called while the device and all its vrings are stopped
479  * @dev: The vhost device to which to send the state
480  * @f: Migration stream from which to load the state