Re: [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on save/restore or migrate

["Durrant, Paul" <pdurrant@xxxxxxxxxxxx>]

> -----Original Message-----
> From: Wei Liu <wl@xxxxxxx>
> Sent: 31 January 2020 16:08
> To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Cc: Durrant, Paul <pdurrant@xxxxxxxxxxxx>; Ian Jackson
> <ian.jackson@xxxxxxxxxx>; Anthony Perard <anthony.perard@xxxxxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx; Wei Liu <wl@xxxxxxx>
> Subject: Re: [Xen-devel] [PATCH v4 7/7] xl: allow domid to be preserved on
> save/restore or migrate
> 
> On Thu, Jan 30, 2020 at 06:20:08PM +0000, Andrew Cooper wrote:
> > On 30/01/2020 17:42, Durrant, Paul wrote:
> > >> -----Original Message-----
> > >> From: Ian Jackson <ian.jackson@xxxxxxxxxx>
> > >> Sent: 30 January 2020 17:29
> > >> To: Durrant, Paul <pdurrant@xxxxxxxxxxxx>
> > >> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Wei Liu <wl@xxxxxxx>; Anthony
> Perard
> > >> <anthony.perard@xxxxxxxxxx>
> > >> Subject: Re: [PATCH v4 7/7] xl: allow domid to be preserved on
> > >> save/restore or migrate
> > >>
> > >> Paul Durrant writes ("[PATCH v4 7/7] xl: allow domid to be preserved
> on
> > >> save/restore or migrate"):
> > >>> This patch adds a '-D' command line option to save and migrate to
> allow
> > >>> the domain id to be incorporated into the saved domain configuration
> and
> > >>> hence be preserved.
> > >> Thanks.
> > >>
> > >> In response to v3 6/6 I wrote:
> > >>
> > >>   I wonder if this should be done more in libxl.  Should this be a
> > >>   domain property ?  Wei, Anthony ?
> > >>
> > >> This question remains unanswered.  I'm sorry that neither Wei nor
> > >> Anthony had a chance to answer yet...
> > >>
> > >> Paul, do you have a reason for doing it this way ?  My inclination is
> > >> that think doing it at the libxl layer would make more sense.  Do you
> > >> think that would be possible ?
> > >>
> > > I'm not sure how it would work at the libxl level as the domid is
> > > part of create_info and that it transferred by xl on migration. IIUC
> > > we'd need a new libxl save record to transfer it at that level, and
> > > then I'm not sure whether we'd hit an ordering problem as we'd have
> > > to dig that save record out before we could actually create the
> > > domain.
> >
> > There is definitely an ordering problem.
> >
> > I agree that it should logically be part of the libxl level of the
> > stream, but none of that is even parsed until after the domain has been
> > created on the destination side.
> >
> > I have no idea how easy/difficult it would be to rearrange libxl to
> > start parsing the migration stream before creating the domain.  I think
> > there will be a lot of code relying on the domid already being valid.
> 
> This.
> 
> The other way I can think of is to specify something (domid policy??) in
> create_info and apply it during domain creation. But that reeks like a
> layering violation to me.
> 

That's basically what this series does, but I don't see it as a layering 
violation. It has always been the case that xl is in control of the domain 
creation and then passes the migration stream into libxl. Passing in a 'domid 
policy' (specific value, 'random', or 'allocated by Xen') as part of 
create_info, and not messing with the libxl migration data, seems like the 
right approach to me... which is why I've done it that way.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel