All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: mst@redhat.com, vkaplans@redhat.com, jasowang@redhat.com,
	wexu@redhat.com, peterx@redhat.com, yuanhan.liu@linux.intel.com,
	virtio-comment@lists.oasis-open.org, qemu-devel@nongnu.org
Cc: Maxime Coquelin <maxime.coquelin@redhat.com>
Subject: [Qemu-devel] [RFC 2/2] spec/vhost-user spec: Add IOMMU support
Date: Tue, 11 Apr 2017 12:10:02 +0200	[thread overview]
Message-ID: <20170411101002.28451-3-maxime.coquelin@redhat.com> (raw)
In-Reply-To: <20170411101002.28451-1-maxime.coquelin@redhat.com>

This patch specifies the master/slave communication to support
device IOTLB implementation 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>
---
 docs/specs/vhost-user.txt | 56 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/docs/specs/vhost-user.txt b/docs/specs/vhost-user.txt
index b365047..048a4d6 100644
--- a/docs/specs/vhost-user.txt
+++ b/docs/specs/vhost-user.txt
@@ -97,6 +97,23 @@ 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 guest I/O virtual address
+   Size: a 64-bit size
+   User address: a 64-bit user address
+   Permissions flags: a 8-bit bit field:
+    - Bit 0: Read access
+    - Bit 1: 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 +126,7 @@ typedef struct VhostUserMsg {
         struct vhost_vring_addr addr;
         VhostUserMemory memory;
         VhostUserLog log;
+        struct vhost_iotlb_msg iotlb;
     };
 } QEMU_PACKED VhostUserMsg;
 
@@ -258,6 +276,30 @@ 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 has
+to send IOTLB entries update & invalidation by sending VHOST_USER_IOTLB_MSG
+requests to the slave with a struct vhost_iotlb_msg 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. For invalidation events, the iotlb payload has to be filled with the
+update 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.
+
+When the VHOST_USER_PROTOCOL_F_SLAVE_REQ is supported by the slave, and the
+master initiated the slave to master communication channel using the
+VHOST_USER_SET_SLAVE_REQ_FD request, the slave can send IOTLB miss and access
+failure events by sending VHOST_USER_IOTLB_MSG requests to the master with a
+struct vhost_iotlb_msg 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. On success, the master is expected to reply  when the
+request has been handled (for example, on miss requests, once the device IOTLB
+has been updated) with a zero payload, non-zero otherwise.
+
 Protocol features
 -----------------
 
@@ -524,6 +566,20 @@ Message types
       has been negotiated, and protocol feature bit VHOST_USER_PROTOCOL_F_SLAVE_REQ
       bit is present in VHOST_USER_GET_PROTOCOL_FEATURES.
 
+ * VHOST_USER_IOTLB_MSG
+
+      Id: 22
+      Equivalent ioctl: N/A (equivalent to VHOST_IOTLB_MSG message type)
+      Initiator: Master or slave
+
+      Send IOTLB messages with struct vhost_iotlb_msg as payload.
+      Master sends such requests to update and invalidate entries in the device
+      IOTLB. Slave sends such requests to notify of an IOTLB miss, or an IOTLB
+      access failure. The recipient 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.
+
 VHOST_USER_PROTOCOL_F_REPLY_ACK:
 -------------------------------
 The original vhost-user specification only demands replies for certain
-- 
2.9.3

  parent reply	other threads:[~2017-04-11 10:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-11 10:10 [Qemu-devel] [RFC 0/2] vhost-user: Specify device IOTLB support Maxime Coquelin
2017-04-11 10:10 ` [Qemu-devel] [RFC 1/2] spec/vhost-user: Introduce secondary channel for slave initiated requests Maxime Coquelin
2017-04-11 13:06   ` Marc-André Lureau
2017-04-11 13:53     ` Maxime Coquelin
2017-04-14  9:03       ` Marc-André Lureau
2017-04-24  8:05         ` [Qemu-devel] [virtio-comment] " Wei Wang
2017-04-25 11:55           ` Maxime Coquelin
2017-04-26 11:29             ` Wei Wang
2017-04-11 10:10 ` Maxime Coquelin [this message]
2017-04-11 13:20   ` [Qemu-devel] [RFC 2/2] spec/vhost-user spec: Add IOMMU support Peter Xu
2017-04-11 15:16     ` Maxime Coquelin
2017-04-12  7:17       ` Peter Xu
2017-04-12  7:24         ` Maxime Coquelin
2017-04-12  7:49           ` Peter Xu
2017-04-12  9:00           ` Jason Wang
2017-04-12  8:54         ` Jason Wang
2017-04-12  9:26           ` Peter Xu
2017-04-13  7:12             ` Jason Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170411101002.28451-3-maxime.coquelin@redhat.com \
    --to=maxime.coquelin@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=vkaplans@redhat.com \
    --cc=wexu@redhat.com \
    --cc=yuanhan.liu@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.