Re: [Qemu-devel] [PATCH v2 04/10] migration: detect compression and decompression errors

[Peter Xu <peterx@redhat.com>]

On Fri, Mar 30, 2018 at 11:11:27AM +0800, Xiao Guangrong wrote:
> 
> 
> On 03/29/2018 12:25 PM, Peter Xu wrote:
> > On Thu, Mar 29, 2018 at 11:51:03AM +0800, Xiao Guangrong wrote:
> > > 
> > > 
> > > On 03/28/2018 05:59 PM, Peter Xu wrote:
> > > > On Tue, Mar 27, 2018 at 05:10:37PM +0800, guangrong.xiao@gmail.com wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > -static int compress_threads_load_setup(void)
> > > > > +static int compress_threads_load_setup(QEMUFile *f)
> > > > >    {
> > > > >        int i, thread_count;
> > > > > @@ -2665,6 +2685,7 @@ static int compress_threads_load_setup(void)
> > > > >            }
> > > > >            decomp_param[i].stream.opaque = &decomp_param[i];
> > > > > +        decomp_param[i].file = f;
> > > > 
> > > > On the source side the error will be set via:
> > > > 
> > > >           qemu_file_set_error(migrate_get_current()->to_dst_file, blen);
> > > > 
> > > > Maybe we can do similar things using migrate_incoming_get_current() to
> > > > avoid caching the QEMUFile multiple times?
> > > > 
> > > 
> > > I have considered it, however, it can not work as the @file used by ram
> > > loader is not the file got from migrate_incoming_get_current() under some
> > > cases.
> > > 
> > > For example, in colo_process_incoming_thread(), the file passed to
> > > qemu_loadvm_state() is a internal buffer and it is not easy to switch it
> > > to incoming file.
> > 
> > I see. How about cache it in a global variable?  We have these
> > already:
> > 
> >      thread_count = migrate_decompress_threads();
> >      decompress_threads = g_new0(QemuThread, thread_count);
> >      decomp_param = g_new0(DecompressParam, thread_count);
> >      ...
> > 
> > IMHO we can add a new one too, at least we don't cache it multiple
> > times (after all decomp_param[i]s are global variables too).
> > 
> 
> Nice, that's good to me. Will add your Reviewed-by on this patch
> as well if you do not mind. :)

Yes, please. :)

Thanks,

-- 
Peter Xu