Lines Matching full:back
27 *back-end*. The *front-end* is the application that shares its virtqueues, in
28 our case QEMU. The *back-end* is the consumer of the virtqueues.
30 In the current implementation QEMU is the *front-end*, and the *back-end*
33 or a block device back-end processing read & write to a virtual
34 disk. In order to facilitate interoperability between various back-end
38 The *front-end* and *back-end* can be either a client (i.e. connecting) or
55 available, QEMU will automatically fall back to pipe2 or, as a last
80 - Bit 2 is the reply flag - needs to be sent on each reply from the back-end
124 back-end will process. This is a free-running index that is not
140 back-end will process. This is a free-running index that is not
143 - Bits 16–30: Index of the entry in the *Used Ring* where the back-end
201 back-end. The back-end shouldn't try to map the entire region at once, as the
202 front-end may not allow it. The back-end should rather map only the required
337 - 0: Save: Transfer the state from the back-end to the front-end,
339 - 1: Load: Transfer the state from the front-end to the back-end,
386 the *back-end* sending message replies. Most of the requests don't require
418 If *back-end* detects some error such as incompatible features, it may also
422 allows full backwards compatibility on both front-end and back-end. As
423 older back-ends don't support negotiating protocol features, a feature
436 fashion. Old vhost-user front-end and back-end implementations continue to
445 * While a ring is stopped, the back-end must not process the ring at
450 * started and disabled: The back-end must process the ring without
452 in the disabled state the back-end must not supply any new RX packets,
455 * started and enabled: The back-end must process the ring normally, i.e.
458 Each ring is initialized in a stopped and disabled state. The back-end
469 back-end must enable all rings immediately.
471 While processing the rings (whether they are enabled or not), the back-end
492 back-end.
495 number of virtqueues is chosen by the back-end. The number can depend on host
496 resource availability or back-end implementation details. Such devices are called
499 Multiple queue support allows the back-end to advertise the maximum number of
500 queues. This is treated as a protocol extension, hence the back-end has to
504 The max number of queues the back-end supports can be queried with message
514 Back-ends should always implement the ``VHOST_USER_PROTOCOL_F_MQ`` protocol
526 the back-end makes to the memory mapped regions. The front-end should mark
544 ``VHOST_USER_SET_LOG_BASE`` message when the back-end has
577 In postcopy migration the back-end is started before all the memory has
579 accessing pages that have yet to be received. The back-end opens a
581 passed back over to the front-end. The front-end services requests on the
584 back-end. The front-end indicates support for this via the
589 Migrating back-end state
593 back-end, called the source, to another back-end, called the
603 provides functionality to have the front-end include the back-end's
604 state in this transfer operation so the back-end does not need to
609 To do this, the back-end state is transferred from back-end to front-end
616 it from the back-end to the front-end. On the destination, the data
617 is loaded, transferring it from the front-end to the back-end.
632 * When saving, the writing end is the source back-end, and the reading
638 reading end is the destination back-end. After reading the state data
639 from the channel, the destination back-end must deserialize its
649 to a vhost-user back-end: This includes, for example, setting up memory
657 verify that data transfer was successful in the back-end, too. The
658 back-end responds once it knows whether the transfer and processing was
664 The front-end sends a list of vhost memory regions to the back-end using the
690 ``VHOST_USER_IOTLB_MSG`` requests to the back-end with a ``struct
697 (3), the I/O virtual address and the size. On success, the back-end is
700 The back-end relies on the back-end communication channel (see :ref:`Back-end
708 the permissions flags. For synchronization purpose, the back-end may
711 back-ends requests a reply. For miss events, completed operation means
717 messages, as the back-end sends IOTLB miss messages for the guest virtual
722 Back-end communication
725 An optional communication channel is provided if the back-end declares
727 back-end to make requests to the front-end.
731 A back-end may then send ``VHOST_USER_BACKEND_*`` messages to the front-end
735 negotiated, back-end can send file descriptors (at most 8 descriptors in
742 To support reconnecting after restart or crash, back-end may need to
750 this problem, the back-end need to allocate an extra buffer to store this
754 between front-end and back-end. And the format of this buffer is described
761 N is the number of available virtqueues. The back-end could get it from num
794 * The back-end could get it from queue size field of VhostUserInflight. */
901 * The back-end could get it from queue size field of VhostUserInflight. */
993 back-end has submitted the buffer to guest driver before crash, so
1000 (roll back any in-progress update)
1022 the former is necessary for getting a message channel from the back-end
1026 use case.) As it has no other way of signalling this error, the back-end
1067 Feature bit ``VHOST_USER_F_PROTOCOL_FEATURES`` signals back-end support
1079 back-end support for ``VHOST_USER_GET_PROTOCOL_FEATURES`` and
1095 Back-ends that report ``VHOST_USER_F_PROTOCOL_FEATURES`` must
1112 Back-ends that report ``VHOST_USER_F_PROTOCOL_FEATURES`` must support
1122 as the front-end that owns of the session. This can be used on the *back-end*
1133 rings, but some back-ends interpreted it to also discard connection
1135 that back-ends either ignore this message, or use it to disable all
1144 Sets the memory map regions on the back-end so it can translate the
1151 regions to the front-end. The back-end must have mmap'd the regions but
1157 reply back to the list of mappings with an empty
1170 When the back-end has ``VHOST_USER_PROTOCOL_F_LOG_SHMFD`` protocol feature,
1313 Query how many queues the back-end supports.
1325 Signal the back-end to enable or disable corresponding vring.
1336 Ask vhost user back-end to broadcast a fake RARP to notify the migration
1344 back-end to construct and broadcast the fake RARP.
1360 If ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` is negotiated, the back-end must
1370 Set the socket file descriptor for back-end initiated requests. It is passed
1377 ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` is negotiated, the back-end must
1389 device IOTLB. The back-end has to acknowledge the request with sending
1419 virtio device configuration space, vhost-user back-end's payload size
1420 MUST match the front-end's request, vhost-user back-end uses zero length of
1434 on the destination host. The vhost-user back-end must check the flags
1435 field, and back-ends MUST NOT accept SET_CONFIG for read-only
1444 Create a session for crypto operation. The back-end must return
1471 advises back-end that a migration with postcopy enabled is underway,
1472 the back-end must open a userfaultfd for later use. Note that at this
1480 The front-end advises back-end that a transition to postcopy mode has
1481 happened. The back-end must ensure that shared memory is registered
1492 The front-end advises that postcopy migration has now completed. The back-end
1510 get a shared buffer from back-end. The shared buffer will be used to
1511 track inflight I/O by back-end. QEMU should retrieve a new one when vm
1522 send the shared inflight buffer back to the back-end so that the back-end
1541 Ask the vhost user back-end to disable all rings and reset all
1543 reinitialized. The back-end retains ownership of the device
1547 feature is set by the back-end.
1559 descriptor or having the back-end rely on polling.
1571 by the front-end to the back-end. The back-end should return the message with a
1573 QEMU to expose to the guest. The value returned by the back-end
1585 by the front-end to the back-end. The message payload contains a memory
1587 the back-end device must map in. When the
1591 update the memory tables of the back-end device.
1596 In postcopy mode (see ``VHOST_USER_POSTCOPY_LISTEN``), the back-end
1609 by the front-end to the back-end. The message payload contains a memory
1611 the back-end device must unmap. When the
1615 update the memory tables of the back-end device.
1621 compatibility with existing incorrect implementations, the back-end MAY
1623 passed, the back-end MUST close it without using it otherwise.
1633 notify the back-end with updated device status as defined in the Virtio
1644 query the back-end for its device status as defined in the Virtio
1656 to retrieve a given dma-buf fd from a given back-end, determined by
1657 the requested UUID. Back-end will reply passing the fd when the operation
1666 Front-end and back-end negotiate a channel over which to transfer the
1667 back-end's internal state during migration. Either side (front-end or
1668 back-end) may create the channel. The nature of this channel is not
1674 * For the writing end, it must allow writing the whole back-end state
1678 * For the reading end, it must allow reading the whole back-end state
1685 passes the FD to the back-end as ancillary data of a
1686 ``VHOST_USER_SET_DEVICE_STATE_FD`` message. The back-end may create a
1687 different transfer channel, passing the respective FD back to the
1689 then discard its channel and use the one provided by the back-end.
1691 Whether the back-end should decide to use its own channel is decided
1696 back-end can provide such a channel, it should decide to use it.
1699 transfer, as described in the :ref:`Migrating back-end state
1703 file descriptor for a back-end-provided channel is returned: Bits 0–7
1707 descriptor as its end of the transfer channel. The back-end must not
1719 After transferring the back-end's internal state during migration (see
1720 the :ref:`Migrating back-end state <migrating_backend_state>`
1721 section), check whether the back-end was able to successfully fully
1730 Back-end message types
1733 For this type of message, the request is sent by the back-end and the reply
1743 The back-end sends such requests to notify of an IOTLB miss, or an IOTLB
1745 negotiated, and back-end set the ``VHOST_USER_NEED_REPLY`` flag, the front-end
1758 back-end sends such messages to notify that the virtio device's
1761 message to the back-end to get the latest content. If
1762 ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` is negotiated, and the back-end sets the
1781 MMIO region. The back-end sends this request to tell QEMU to de-register
1797 submitted by the back-end to indicate that a buffer was used from
1811 submitted by the back-end to indicate that an error occurred on the
1826 table. The back-end device gets associated with a UUID in the shared table.
1827 The back-end is responsible of keeping its own table with exported dma-buf fds.
1828 When another back-end tries to import the resource associated with the UUID,
1830 exporter back-end. If ``VHOST_USER_PROTOCOL_F_REPLY_ACK`` is negotiated, and
1831 the back-end sets the ``VHOST_USER_NEED_REPLY`` flag, the front-end must
1844 table API. Only the back-end owning the entry (i.e., the one that first added
1846 The shared table will remove the back-end device associated with
1848 back-end sets the ``VHOST_USER_NEED_REPLY`` flag, the front-end must respond
1871 commands are sent over an ``ioctl()`` call and block until the back-end
1876 back-end MUST respond with a Payload ``VhostUserMsg`` indicating success
1885 For the message types that already solicit a reply from the back-end,
1895 vhost-user back-ends can provide various devices & services and may
1900 back-end programs and facilitate interoperability.
1902 Each back-end installed on a host system should come with at least one
1904 informs the management applications about the back-end type, and binary
1906 picking the highest priority back-end when multiple match the search
1909 If the back-end is not capable of enabling a requested feature on the
1911 failed, the back-end should fail to start early and exit with a status
1914 The back-end program must not daemonize itself, but it may be
1922 The back-end program must end (as quickly and cleanly as possible) when
1936 When this argument is given, the back-end program is started with the
1942 Output to stdout the back-end capabilities in JSON format, and then
1944 the back-end program should not perform its normal function. The