On Tue, Mar 06, 2018 at 11:20:56AM +0000, Dr. David Alan Gilbert wrote: > * Peter Xu (pet...@redhat.com) wrote: > > On Mon, Mar 05, 2018 at 05:42:42PM +0000, Dr. David Alan Gilbert wrote: > > > * Peter Xu (pet...@redhat.com) wrote: > > > > On Fri, Feb 16, 2018 at 01:16:07PM +0000, Dr. David Alan Gilbert (git) > > > > wrote: > > > > > > > > [...] > > > > > > > > > typedef struct VuVirtqElement { > > > > > diff --git a/docs/interop/vhost-user.txt b/docs/interop/vhost-user.txt > > > > > index 621543e654..bdec9ec0e8 100644 > > > > > --- a/docs/interop/vhost-user.txt > > > > > +++ b/docs/interop/vhost-user.txt > > > > > @@ -682,6 +682,12 @@ Master message types > > > > > the slave must open a userfaultfd for later use. > > > > > Note that at this stage the migration is still in precopy mode. > > > > > > > > > > + * VHOST_USER_POSTCOPY_LISTEN > > > > > + Id: 27 > > > > > + Master payload: N/A > > > > > + > > > > > + Master advises slave that a transition to postcopy mode has > > > > > happened. > > > > > > > > Could we add something to explain why this listen needs to be > > > > broadcasted to clients? Since I failed to find it out quickly > > > > myself. :( > > > > > > I've changed this to: > > > > > > * VHOST_USER_POSTCOPY_LISTEN > > > Id: 29 > > > Master payload: N/A > > > > > > Master advises slave that a transition to postcopy mode has > > > happened. > > > The slave must ensure that shared memory is registered with > > > userfaultfd > > > to cause faulting of non-present pages. > > > > But shouldn't this be assured by the SET_MEM_TABLE call? > > Yes, it is the set_mem_table that does the register - but it only > registers it with userfaultfd if it's received a 'listen' notification, > otherwise it assumes it's a normal precopy migration.
I think I got the picture now. Please add this after the enhanced document: Reviewed-by: Peter Xu <pet...@redhat.com> Thanks, -- Peter Xu