motorhead/qemu
1
0
Fork 0
mirror of https://github.com/Motorhead1991/qemu.git synced 2025-08-03 15:53:54 -06:00
Code Issues Projects Releases Packages Wiki Activity Actions

spec/vhost-user spec: Add IOMMU support

Browse source 
This patch specifies and implements the master/slave communication
to support device IOTLB in slave.

The vhost_iotlb_msg structure introduced for kernel backends is
re-used, making the design close between the two backends.

An exception is the use of the secondary channel to enable the
slave to send IOTLB miss requests to the master.

Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This commit is contained in:
Maxime Coquelin 2017-06-02 12:18:31 +02:00 • committed by Michael S. Tsirkin
parent 4bbeeba023
commit 6dcdd06e3b
3 changed files with 130 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

84
docs/specs/vhost-user.txt
View file

@ -97,6 +97,25 @@ Depending on the request type, payload can be:
log offset: offset from start of supplied file descriptor
where logging starts (i.e. where guest address 0 would be logged)
* An IOTLB message
---------------------------------------------------------
| iova | size | user address | permissions flags | type |
---------------------------------------------------------
IOVA: a 64-bit I/O virtual address programmed by the guest
Size: a 64-bit size
User address: a 64-bit user address
Permissions: a 8-bit value:
- 0: No access
- 1: Read access
- 2: Write access
- 3: Read/Write access
Type: a 8-bit IOTLB message type:
- 1: IOTLB miss
- 2: IOTLB update
- 3: IOTLB invalidate
- 4: IOTLB access fail
In QEMU the vhost-user message is implemented with the following struct:
typedef struct VhostUserMsg {
@ -109,6 +128,7 @@ typedef struct VhostUserMsg {
struct vhost_vring_addr addr;
VhostUserMemory memory;
VhostUserLog log;
struct vhost_iotlb_msg iotlb;
};
} QEMU_PACKED VhostUserMsg;
@ -253,6 +273,38 @@ Once the source has finished migration, rings will be stopped by
the source. No further update must be done before rings are
restarted.
IOMMU support
-------------
When the VIRTIO_F_IOMMU_PLATFORM feature has been negotiated, the master
sends IOTLB entries update & invalidation by sending VHOST_USER_IOTLB_MSG
requests to the slave with a struct vhost_iotlb_msg as payload. For update
events, the iotlb payload has to be filled with the update message type (2),
the I/O virtual address, the size, the user virtual address, and the
permissions flags. Addresses and size must be within vhost memory regions set
via the VHOST_USER_SET_MEM_TABLE request. For invalidation events, the iotlb
payload has to be filled with the invalidation message type (3), the I/O virtual
address and the size. On success, the slave is expected to reply with a zero
payload, non-zero otherwise.
The slave relies on the slave communcation channel (see "Slave communication"
section below) to send IOTLB miss and access failure events, by sending
VHOST_USER_SLAVE_IOTLB_MSG requests to the master with a struct vhost_iotlb_msg
as payload. For miss events, the iotlb payload has to be filled with the miss
message type (1), the I/O virtual address and the permissions flags. For access
failure event, the iotlb payload has to be filled with the access failure
message type (4), the I/O virtual address and the permissions flags.
For synchronization purpose, the slave may rely on the reply-ack feature,
so the master may send a reply when operation is completed if the reply-ack
feature is negotiated and slaves requests a reply. For miss events, completed
operation means either master sent an update message containing the IOTLB entry
containing requested address and permission, or master sent nothing if the IOTLB
miss message is invalid (invalid IOVA or permission).
The master isn't expected to take the initiative to send IOTLB update messages,
as the slave sends IOTLB miss messages for the guest virtual memory areas it
needs to access.
Slave communication
-------------------
@ -514,6 +566,38 @@ Master message types
If VHOST_USER_PROTOCOL_F_REPLY_ACK is negotiated, slave must respond
with zero for success, non-zero otherwise.
* VHOST_USER_IOTLB_MSG
Id: 22
Equivalent ioctl: N/A (equivalent to VHOST_IOTLB_MSG message type)
Master payload: struct vhost_iotlb_msg
Slave payload: u64
Send IOTLB messages with struct vhost_iotlb_msg as payload.
Master sends such requests to update and invalidate entries in the device
IOTLB. The slave has to acknowledge the request with sending zero as u64
payload for success, non-zero otherwise.
This request should be send only when VIRTIO_F_IOMMU_PLATFORM feature
has been successfully negotiated.
Slave message types
-------------------
* VHOST_USER_SLAVE_IOTLB_MSG
Id: 1
Equivalent ioctl: N/A (equivalent to VHOST_IOTLB_MSG message type)
Slave payload: struct vhost_iotlb_msg
Master payload: N/A
Send IOTLB messages with struct vhost_iotlb_msg as payload.
Slave sends such requests to notify of an IOTLB miss, or an IOTLB
access failure. If VHOST_USER_PROTOCOL_F_REPLY_ACK is negotiated,
and slave set the VHOST_USER_NEED_REPLY flag, master must respond with
zero when operation is successfully completed, or non-zero otherwise.
This request should be send only when VIRTIO_F_IOMMU_PLATFORM feature
has been successfully negotiated.
VHOST_USER_PROTOCOL_F_REPLY_ACK:
-------------------------------
The original vhost-user specification only demands replies for certain