[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [PATCH v4 0/2] vhost-user: Extend protocol to receive repli
From: |
Prerna Saxena |
Subject: |
[Qemu-devel] [PATCH v4 0/2] vhost-user: Extend protocol to receive replies on any command. |
Date: |
Wed, 27 Jul 2016 02:52:35 -0700 |
From: Prerna Saxena <address@hidden>
*** BLURB HERE ***
vhost-user: Extend protocol to receive replies on any command.
The current vhost-user protocol requires the client to send responses to only a
few commands. For the remaining commands, it is impossible for QEMU to know the
status of the requested operation -- ie, did it succeed? If so, by 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).Note that SET_MEM_TABLE does not 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 does not 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.
Patch 1 introduces a protocol extension, VHOST_USER_PROTOCOL_F_REPLY_ACK. This
feature, if negotiated, allows QEMU to request a response to any message by
setting the newly introduced "need_response" flag. The application must then
respond to qemu by providing a status about the requested operation.
Patch 2 adds a workaround for the race described above for clients that do not
support REPLY_ACK
feature. it introduces a get_features command to be sent before returning from
set_mem_table. While this is not a complete fix, it will help client
applications that strictly process messagesin order.
Changelog:
----------
Changes v3->v4:
1) Rearranged code in PATCH 1 to offset compiler warnings about missing
declaration of vhost_user_read(). Fixed by moving process_message_reply() after
definition of vhost_user_read()
2) Fixed minor suggestions in writeup for this protocol extension.
Changes v2->v3:
1) Swapped the patch numbers 1 & 2 from the previous series.
2) Patch 1 (previously patch 2 in v2): addresses MarcAndre's review comments
and renames function 'process_message_response' to 'process_message_reply'
3) Patch 2 (ie patch 1 in v2) : Unchanged from v2.
Changes v1->v2:
1) Patch 1 : Ask for get_features before returning from set_mem_table(new).
2) Patch 2 : * Improve documentation.
* Abstract out commonly used operations in the form of a function,
process_message_response(). Also implement this only for SET_MEM_TABLE.
References:
v1 : https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07152.html
v2 : https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg00048.html
v3 : https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg01598.html
Prerna Saxena (2):
vhost-user: Introduce a new protocol feature REPLY_ACK.
vhost-user: Attempt to fix a race with set_mem_table.
docs/specs/vhost-user.txt | 44 +++++++++++++++
hw/virtio/vhost-user.c | 133 ++++++++++++++++++++++++++++++----------------
2 files changed, 130 insertions(+), 47 deletions(-)
--
1.8.1.2
Prerna Saxena (2):
vhost-user: Introduce a new protocol feature REPLY_ACK.
vhost-user: Attempt to fix a race with set_mem_table.
docs/specs/vhost-user.txt | 41 ++++++++++++++
hw/virtio/vhost-user.c | 133 ++++++++++++++++++++++++++++++----------------
2 files changed, 127 insertions(+), 47 deletions(-)
--
1.8.1.2
- [Qemu-devel] [PATCH v4 0/2] vhost-user: Extend protocol to receive replies on any command.,
Prerna Saxena <=
[Qemu-devel] [PATCH v4 2/2] vhost-user: Attempt to fix a race with set_mem_table., Prerna Saxena, 2016/07/27