Re: [Xen-devel] [PATCH RFC XEN v1 11/14] tools: migrate: refactor selection of save/restore ops to be arch specific

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-12-09 at 15:26 +0000, Andrew Cooper wrote:
> On 09/12/15 14:32, Ian Campbell wrote:
> > I wasn't sure of the best way to achieve this, but a pair of per-arch
> > hooks seemed to be preferable to ifdeffery.
> 
> I agree.ÂÂThe patch looks good.
> 
> > 
> > I also wasn't sure about the change to guest_type for save. The
> > restore half of the ctxt already has such a field but since the save
> > side treats it as an input to the process as opposed to the restore
> > side which determines it from the stream it seemed like keeping them
> > separate was best.
> 
> I would recommend introducing a const uint32_t field in xc_sr_save_ops,
> to make it harder to accidentally get the guest type out of sync with
> the ops in use.

Good idea. It seems unlikely that we would end up with the same set of
xc_sr_*_ops for different types of guest, and if we do then dupping the
struct seems reasonable.

Maybe as a stretch it would be interesting to have such a field in the
restore ops and have an array of possible ops which some generic code can
iterate over. Given just x86 PV vs HVM it maybe isn't worth it though.

> The save/restore difference is because of the asymetry in their use. 
> The save side needs to select the correct one to used, based on the
> domid, while the restore side gets one in the migration stream and has
> to verify it against the domain it is restoring into.

Right, that's what I said, I think.
> 
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > Cc: andyhhp
> 
> I don't think that is quite enough routing information to find me ;)

It was an experiment to see if git send-email would consult ~/.gitaliases.
TL:DR; it doesn't (also I forgot I'd done this and --cc'd you anyway...).

Ian.

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