From: Prerna Saxena <saxenap.ltc@gmail.com>
To: qemu-devel@nongnu.org
Cc: felipe.francoisi@nutanix.com, anilkumar.boggarapu@nutanix.com,
Prerna Saxena <prerna.saxena@nutanix.com>
Subject: [Qemu-devel] [PATCH 0/1] vhost-user: Add a protocol extension for client responses to vhost commands.
Date: Fri, 24 Jun 2016 01:17:07 -0700 [thread overview]
Message-ID: <1466756228-27490-1-git-send-email-saxenap.ltc@gmail.com> (raw)
From: Prerna Saxena <prerna.saxena@nutanix.com>
The current vhost-user protocol requires the client to send responses to only few commands. For the remaining commands, it is impossible for QEMU to know the status of the requested operation -- ie, did it succeed at all, and if so, at what time.
This is inconvenient, and can also lead to races. As an example:
(1) qemu sends a SET_MEM_TABLE to the backend (eg, a vhost-user net application) and SET_MEM_TABLE doesn't require a reply according to the spec.
(2) qemu commits the memory to the guest.
(3) guest issues an I/O operation over a new memory region which was configured on (1)
(4) The application hasn't yet remapped the memory, but it sees the I/O request.
(5) The application cannot satisfy the request because it doesn't know about those GPAs
Note that the kernel implementation does not suffer from this limitation since messages are sent via an ioctl(). The ioctl() blocks until the backend (eg. vhost-net) completes the command and returns (with an error code).
Changing the behaviour of current vhost-user commands would break existing applications. This patch introduces a protocol extension, VHOST_USER_PROTOCOL_F_REPLY_ACK. This feature, if negotiated, allows QEMU to annotate messages to the application that it seeks a response for. The application must then respond to qemu by providing a status about the requested operation.
Prerna Saxena (1):
vhost-user : Introduce a new feature, VHOST_USER_PROTOCOL_F_REPLY_ACK
This feature, if negotiated, forces the remote vhost-user
process to send a u64 reply containin status code for each
requested operation.
Status codes are '0' for success, and non-zero for error.
docs/specs/vhost-user.txt | 36 +++++++++++
hw/virtio/vhost-user.c | 153 +++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 186 insertions(+), 3 deletions(-)
--
1.8.1.2
next reply other threads:[~2016-06-24 8:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-24 8:17 Prerna Saxena [this message]
2016-06-24 8:17 ` [Qemu-devel] [PATCH 1/1] vhost-user : Introduce a new feature VHOST_USER_PROTOCOL_F_REPLY_ACK. This feature, if negotiated, forces the remote vhost-user process to send a u64 reply containing a status code for each requested operation. Status codes are '0' for success, and non-zero for error Prerna Saxena
2016-06-24 8:35 ` Prerna
2016-06-24 22:48 ` Michael S. Tsirkin
2016-06-24 8:30 ` [Qemu-devel] [PATCH 0/1] vhost-user: Add a protocol extension for client responses to vhost commands Prerna
2016-06-24 13:59 ` Marc-André Lureau
2016-06-24 15:45 ` Felipe Franciosi
2016-06-24 17:39 ` Prerna Saxena
2016-06-24 23:13 ` Michael S. Tsirkin
2016-06-25 3:13 ` Prerna Saxena
2016-06-26 2:45 ` Michael S. Tsirkin
2016-06-26 2:48 ` Prerna Saxena
2016-06-26 2:51 ` Michael S. Tsirkin
2016-06-24 22:43 ` Michael S. Tsirkin
2016-06-27 10:45 ` Felipe Franciosi
2016-06-27 11:47 ` Marc-André Lureau
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=1466756228-27490-1-git-send-email-saxenap.ltc@gmail.com \
--to=saxenap.ltc@gmail.com \
--cc=anilkumar.boggarapu@nutanix.com \
--cc=felipe.francoisi@nutanix.com \
--cc=prerna.saxena@nutanix.com \
--cc=qemu-devel@nongnu.org \
/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).