On Wed, 08/10 18:30, Michael S. Tsirkin wrote: > From: Prerna Saxena <prerna.sax...@nutanix.com> > > 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.sax...@nutanix.com> > Reviewed-by: Michael S. Tsirkin <m...@redhat.com> > Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
Sporadic hangs are seen with test-vhost-user after this patch: https://travis-ci.org/qemu/qemu/builds Reverting seems to fix it for me. Is this a known problem? Fam
