vhost-user: Attempt to fix a race with set_mem_table.
commit28ed5ef16384f12500abd3647973ee21b03cbe23
authorPrerna Saxena <prerna.saxena@nutanix.com>
Fri, 5 Aug 2016 10:53:51 +0000 (5 03:53 -0700)
committerMichael S. Tsirkin <mst@redhat.com>
Wed, 10 Aug 2016 14:47:29 +0000 (10 17:47 +0300)
tree6ead2ee207fb66683ea496090676d1156a61c57a
parentca525ce5618bea94db0d8fa3fde0b3066f8cd3f0
vhost-user: Attempt to fix a race with set_mem_table.

The set_mem_table command currently does not seek a reply. Hence, there is
no easy way for a remote application to notify to QEMU when it finished
setting up memory, or if there were errors doing so.

As an example:
(1) Qemu sends a SET_MEM_TABLE to the backend (eg, a vhost-user net
application). 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 has not 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.

While a guaranteed fix would require a protocol extension (committed separately),
a best-effort workaround for existing applications is to send a GET_FEATURES
message before completing the vhost_user_set_mem_table() call.
Since GET_FEATURES requires a reply, an application that processes vhost-user
messages synchronously would probably have completed the SET_MEM_TABLE before replying.

Signed-off-by: Prerna Saxena <prerna.saxena@nutanix.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
hw/virtio/vhost-user.c