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

[Wei Liu <wl@xxxxxxx>]

On Sat, Feb 01, 2020 at 11:56:19AM +0000, Durrant, Paul wrote:
> > -----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.

Going through the code more carefully I think your implementation should
be fine.

Wei.

> 
>   Paul

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