28ed5ef163
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> |
||
|---|---|---|
| .. | ||
| Makefile.objs | ||
| trace-events | ||
| vhost-backend.c | ||
| vhost-user.c | ||
| vhost.c | ||
| virtio-balloon.c | ||
| virtio-bus.c | ||
| virtio-mmio.c | ||
| virtio-pci.c | ||
| virtio-pci.h | ||
| virtio-rng.c | ||
| virtio.c | ||