* Liran Alon (liran.alon@xxxxxxxxxx) wrote: > > > > On 31 Oct 2018, at 20:19, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > > > On 31/10/2018 19:17, Eduardo Habkost wrote: > >> On Wed, Oct 31, 2018 at 03:03:34AM +0200, Liran Alon wrote: > >>> Ping. > >>> Patch was submitted almost two months ago and I haven’t seen any respond for the v2 of this series. > >> Sorry for the long delay. This was on my queue of patches to be > >> reviewed, but I'm failing to keep up to the rate of incoming > >> patches. I will try to review the series next week. > > > > I have already reviewed it; unfortunately I have missed the soft freeze > > for posting the version I had also been working on when Liran posted > > these patches. > > > > Paolo > > Paolo, note that this is v2 of this patch series. It’s not the one you have already reviewed. > It now correctly handles the case you mentioned in review of v1 of migrating with various nested_state buffer sizes. > The following scenarios were tested: > (a) src and dest have same nested state size. > ==> Migration succeeds. > (b) src don't have nested state while dest do. > ==> Migration succeed and src don't send it's nested state. > (c) src have nested state while dest don't. > ==> Migration fails as it cannot restore nested state. > (d) dest have bigger max nested state size than src > ==> Migration succeeds. > (e) dest have smaller max nested state size than src but enough to store it's saved nested state > ==> Migration succeeds > (f) dest have smaller max nested state size than src but not enough to store it's saved nested state > ==> Migration fails Is it possible to tell these limits before the start of the migration, or do we only find out that a nested migration won't work by trying it? Dave > -Liran > > -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
