qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: qemu-devel@nongnu.org
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Johannes Berg" <johannes.berg@intel.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>
Subject: [Qemu-devel] [RFC] docs: vhost-user: add in-band kick/call messages
Date: Mon,  2 Sep 2019 14:12:32 +0200	[thread overview]
Message-ID: <20190902121233.13382-2-johannes@sipsolutions.net> (raw)
In-Reply-To: <20190902121233.13382-1-johannes@sipsolutions.net>

From: Johannes Berg <johannes.berg@intel.com>

For good reason, vhost-user is currently built asynchronously, that
way better performance can be obtained. However, for certain use
cases such as simulation, this is problematic.

Consider an event-based simulation in which both the device and CPU
have are scheduled according to a simulation "calendar". Now, for
example, consider the CPU sending a command to the device, over a
vring in the vhost-user protocol. In this case, the CPU must wait
for the vring update to have been processed, so that the device has
time to put an entry onto the simulation calendar to obtain time to
handle the interrupt, before the CPU goes back to scheduling and
thus updates the simulation calendar or even has the simulation
move time forward.

This cannot easily achieved with the eventfd based vring kick/call
design.

Extend the protocol slightly, so that a message can be used for kick
and call instead, if the new VHOST_USER_PROTOCOL_F_KICK_CALL_MSGS is
negotiated. This in itself doesn't guarantee synchronisation, but both
sides can also negotiate VHOST_USER_PROTOCOL_F_REPLY_ACK and thus get
a reply to this message by setting the need_reply flag, and ensure
synchronisation this way.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
 docs/interop/vhost-user.rst | 36 ++++++++++++++++++++++++++++++++++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst
index 7827b710aa0a..1270885fecf2 100644
--- a/docs/interop/vhost-user.rst
+++ b/docs/interop/vhost-user.rst
@@ -2,6 +2,7 @@
 Vhost-user Protocol
 ===================
 :Copyright: 2014 Virtual Open Systems Sarl.
+:Copyright: 2019 Intel Corporation
 :Licence: This work is licensed under the terms of the GNU GPL,
           version 2 or later. See the COPYING file in the top-level
           directory.
@@ -785,6 +786,7 @@ Protocol features
   #define VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD  10
   #define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER  11
   #define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12
+  #define VHOST_USER_PROTOCOL_F_KICK_CALL_MSGS 13
 
 Master message types
 --------------------
@@ -946,7 +948,9 @@ Master message types
   Bits (0-7) of the payload contain the vring index. Bit 8 is the
   invalid FD flag. This flag is set when there is no file descriptor
   in the ancillary data. This signals that polling should be used
-  instead of waiting for a kick.
+  instead of waiting for the call. however, if the protocol feature
+  ``VHOST_USER_PROTOCOL_F_KICK_CALL_MSGS`` has been negotiated it instead
+  means the updates should be done using the messages.
 
 ``VHOST_USER_SET_VRING_CALL``
   :id: 13
@@ -959,7 +963,9 @@ Master message types
   Bits (0-7) of the payload contain the vring index. Bit 8 is the
   invalid FD flag. This flag is set when there is no file descriptor
   in the ancillary data. This signals that polling will be used
-  instead of waiting for the call.
+  instead of waiting for the call; however, if the protocol feature
+  ``VHOST_USER_PROTOCOL_F_KICK_CALL_MSGS`` has been negotiated it instead
+  means the updates should be done using the messages.
 
 ``VHOST_USER_SET_VRING_ERR``
   :id: 14
@@ -1190,6 +1196,19 @@ Master message types
   ancillary data. The GPU protocol is used to inform the master of
   rendering state and updates. See vhost-user-gpu.rst for details.
 
+``VHOST_USER_VQ_CALL``
+  :id: 34
+  :equivalent ioctl: N/A
+  :slave payload: vring state description
+  :master payload: N/A
+
+  When the ``VHOST_USER_PROTOCOL_F_KICK_CALL_MSGS`` protocol feature has
+  been successfully negotiated, this message may be submitted by the master
+  to indicate that a buffer was added to the vring instead of signalling it
+  using the vring's event FD or having the slave rely on polling.
+
+  The state.num field is currently reserved and must be set to 0.
+
 Slave message types
 -------------------
 
@@ -1246,6 +1265,19 @@ Slave message types
   ``VHOST_USER_PROTOCOL_F_HOST_NOTIFIER`` protocol feature has been
   successfully negotiated.
 
+``VHOST_USER_VQ_KICK``
+  :id: 4
+  :equivalent ioctl: N/A
+  :slave payload: vring state description
+  :master payload: N/A
+
+  When the ``VHOST_USER_PROTOCOL_F_KICK_CALL_MSGS`` protocol feature has
+  been successfully negotiated, this message may be submitted by the slave
+  to indicate that a buffer was used from the vring instead of signalling it
+  using the vring's kick FD or having the master relying on polling.
+
+  The state.num field is currently reserved and must be set to 0.
+
 .. _reply_ack:
 
 VHOST_USER_PROTOCOL_F_REPLY_ACK
-- 
2.20.1



  reply	other threads:[~2019-09-02 12:14 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-02 12:12 [Qemu-devel] [RFC] vhost-user simulation extension Johannes Berg
2019-09-02 12:12 ` Johannes Berg [this message]
2019-09-05 20:28   ` [Qemu-devel] [RFC] docs: vhost-user: add in-band kick/call messages Johannes Berg
2019-09-09 16:00     ` Stefan Hajnoczi
2019-09-09 17:34       ` Johannes Berg
2019-09-10 15:03         ` Stefan Hajnoczi
2019-09-10 15:14           ` Johannes Berg
2019-09-10 15:33             ` Michael S. Tsirkin
2019-09-10 15:34               ` Johannes Berg
2019-09-11  6:56                 ` Stefan Hajnoczi
2019-09-11  7:35             ` Stefan Hajnoczi
2019-09-11  8:26               ` Johannes Berg
2019-09-11 15:17                 ` Stefan Hajnoczi
2019-09-11 15:31   ` Stefan Hajnoczi
2019-09-11 15:36     ` Johannes Berg
2019-09-11 15:38       ` Johannes Berg
2019-09-12 12:22       ` Stefan Hajnoczi
2019-09-12 20:37         ` Johannes Berg
2019-09-06 12:13 ` [Qemu-devel] [RFC] libvhost-user: implement VHOST_USER_PROTOCOL_F_KICK_CALL_MSGS Johannes Berg
2019-09-06 14:22   ` Michael S. Tsirkin
2019-09-06 14:48     ` Johannes Berg
2019-09-06 15:12       ` Michael S. Tsirkin
2019-09-06 15:32         ` Johannes Berg
2019-09-08 13:13           ` Michael S. Tsirkin
2019-09-09 11:35             ` Johannes Berg
2019-09-09 12:41               ` Michael S. Tsirkin
2019-09-09 13:05                 ` Johannes Berg
2019-09-09 13:48                   ` Michael S. Tsirkin
2019-09-09 13:50                     ` Johannes Berg
2019-09-09 14:59                       ` Michael S. Tsirkin
2019-09-09 15:26                         ` Johannes Berg
2019-09-09 15:34                           ` Johannes Berg
2019-09-09 15:45                             ` Michael S. Tsirkin
2019-09-09 15:47                               ` Johannes Berg
2019-09-10 15:52                       ` Johannes Berg
2019-09-11  9:16                         ` Michael S. Tsirkin
2019-09-11  9:20                           ` Johannes Berg
2019-09-11  9:54                             ` Michael S. Tsirkin

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=20190902121233.13382-2-johannes@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=johannes.berg@intel.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.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).