On 27/07/16 7:00 pm, "Michael S. Tsirkin" <m...@redhat.com> wrote:
>On Wed, Jul 27, 2016 at 02:52:37AM -0700, Prerna Saxena 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> > >Could you pls reorder patchset so this is 1/2? >1/1 is still under review but I'd like to make sure >we have some kind of fix in place for 2.7. Hi Michael, The review comments for patch 1 were around documentation and the choice of name of flag. There has been no recommendation/comment on the code itself. I have fixed all of that and posted a new patch series. (Version v5.1) Hope both the patches make it in time for 2.7. Thanks, once again, for reviewing this. Regards, Prerna
