qemu-devel.nongnu.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).