Re: [Xen-devel] [PATCH v6 COLO 06/15] libxc/save: support COLO save

[Yang Hongyang <yanghy@xxxxxxxxxxxxxx>]

On 06/09/2015 04:51 PM, Andrew Cooper wrote:
> On 09/06/15 09:45, Yang Hongyang wrote:
> > > > Even if there are no dirty pages on secondary, pfn_list shouldn't be
> > > > NULL, it's just that pfn_list[0] will be 0. if pfn_list is NULL,
> > > > there might be unexpected error happened.
> > > get_dirty_pfn() should be declared alongside a
> > >
> > > struct pfn_data
> > > {
> > >       uint64_t count;
> > >       uint64_t *pfns;
> > > };
> > >
> > > and this function here should create one of these on the stack and pass
> > > it by pointer to get_dirty_pfn().  I might also be tempted to rename
> > > this to get_remote_logdirty() or similar, to indicate that it is a
> > > source of logdirty data from something other than the current
> > > hypervisor.
> > This is a callback, I can't find a way to pass pointer from libxc to
> > libxl,
> > libxl can not access the pointer data...The struct can be used for
> > represent
> > the data however.
> Right - my point is that it should be the implementation of
> get_remote_logdirty() (i.e. in libxl_save_helper) which is responsible
> for unpackaging the data from whatever RPC method is used, rather than
> the caller.
Now I know what you mean, I will fix it in the next version, thanks!

> > > > > Shouldn't get_dirty_pfn be mandatory for COLO streams (even if it is a
> > > > > noop to start with) ?
> > > > It should be mandatory, it shouldn't be noop under COLO. perhaps we
> > > > should
> > > > add sanity check at the beginning. But problem is save side do not
> > > > have a param
> > > > passed from libxl to indicate the stream type(like
> > > > checkpointed_stream in
> > > > restore side). So we may need to add another XCFLAGS? Currently
> > > > there is
> > > > XCFLAGS_CHECKPOINTED which represents Remus, we might need to change
> > > > this to
> > > > XCFLAGS_STREAM_REMUS
> > > > XCFLAGS_STREAM_COLO
> > > > so that we can know what kind of stream we are handling?
> > > checkpointed_stream started out as a bugfix for a legacy stream
> > > migration breakage.  Really, this information should have been passed
> > > right from the start.
> > Did I miss the bugfix? is it not in upstream?
> c/s 7051d5c
Ah, you are talking about the restore side, I'm talking about the save
side checkpointed_stream, so I should also post a prereq patch to
add checkpointed_stream to the save side? or there's already the
fix out there?

> ~Andrew
> .
--
Thanks,
Yang.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel