From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shriram Rajagopalan Subject: Re: [PATCH 09/29] [HACK] tools/libxc: save/restore v2 framework Date: Sun, 14 Sep 2014 03:23:47 -0700 Message-ID: References: <1410369067-1330-1-git-send-email-andrew.cooper3@citrix.com> <1410369067-1330-10-git-send-email-andrew.cooper3@citrix.com> <1410431645.6166.69.camel@kazak.uk.xensource.com> <54117B6F.6010200@citrix.com> <1410433265.6166.86.camel@kazak.uk.xensource.com> <541181D3.5090008@citrix.com> Reply-To: rshriram@cs.ubc.ca Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7100697696313933220==" Return-path: In-Reply-To: <541181D3.5090008@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: FNST-Yang Hongyang , Ian Jackson , Ian Campbell , Xen-devel List-Id: xen-devel@lists.xenproject.org --===============7100697696313933220== Content-Type: multipart/alternative; boundary=001a11c2d9844a233d050303ec7e --001a11c2d9844a233d050303ec7e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sep 11, 2014 4:08 AM, "Andrew Cooper" wrote: > > On 11/09/14 12:01, Ian Campbell wrote: > > On Thu, 2014-09-11 at 11:37 +0100, Andrew Cooper wrote: > >> On 11/09/14 11:34, Ian Campbell wrote: > >>> On Wed, 2014-09-10 at 18:10 +0100, Andrew Cooper wrote: > >>>> For testing purposes, the environmental variable "XG_MIGRATION_V2" allows the > >>>> two save/restore codepaths to coexist, and have a runtime switch. > >>>> > >>>> It is indended that once this series is less RFC, the v2 framework will > >>>> completely replace v1. > >>> I think we are now at the point where this hack needs to be dropped from > >>> the series. > >> One problem is remus. My plan when dropping this patch was to drop al= l > >> of xc_domain_{save/restore}.c as well, but without remus migration-v2 > >> support available, this will break existing set-ups. > > Hrm, how is that going wrt 4.5 freeze? > > I haven=E2=80=99t heard seen anything since v5 of this series (for which = I did > some quick bugfixes and released v6). > FYI, thats not entirely true. Yang did post a set of RFC patches for remus support in migration v2, based on your V6 series (back in July) http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg01163.html It would actually be helpful if you could cc me on the patches relevant to Remus, or if there is anything specific to Remus that needs to be done. There are 100s of posts on Xen devel every day and its hard to keep track of everything posted to Xen devel. And I looking at your patch sets in http://xenbits.xen.org/gitweb/?p=3Dpeople/andrewcoop/xen.git;a=3Dshortlog;h= =3Drefs/heads/saverestore2-v6.3 I see that there is no support for Remus currently. Nor can I differentiate which parts of the code fix to these "quick bug fixes" that you mentioned above. From the discussion over the remus rfc patches, I only recall a bug related to vcpu context caching. But I cannot delineate that specific part from the patches in the repo. So, if these bug fixes you are referring to are something else, please explain. > I don't know, which probably means not good. > > > > >> One option might be to have legacy and v2 sitting properly side-by-sid= e > >> in libxc for the transition period. > > How long do you mean? Until 4.6? > fwiw, I don't plan to work on remus migration v2 support until the remus netbuffer patches get in. I have been at this for almost two release cycles. Its frustrating to iterate on feedbacks for patch 4/11 of a series for two months and then get a bunch of first-pass review for patch 6/10 at the eleventh hour before a feature freeze, while the rest of the series has still not been reviewed at all for the past 3 months. > Ideally, very early in the 4.6 dev period. > > ~Andrew > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel --001a11c2d9844a233d050303ec7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sep 11, 2014 4:08 AM, "Andrew Cooper" <andrew.cooper3@= citrix.com> wrote:
>
> On 11/09/14 12:01, Ian Campbell w= rote:
> > On Thu, 2014-09-11 at 11:37 +0100, Andrew Cooper wrote:<= br>> >> On 11/09/14 11:34, Ian Campbell wrote:
> >>>= ; On Wed, 2014-09-10 at 18:10 +0100, Andrew Cooper wrote:
> >>&= gt;> For testing purposes, the environmental variable "XG_MIGRATION= _V2" allows the
> >>>> two save/restore codepaths to= coexist, and have a runtime switch.
> >>>>
> >&= gt;>> It is indended that once this series is less RFC, the v2 framew= ork will
> >>>> completely replace v1.
> >>&g= t; I think we are now at the point where this hack needs to be dropped from=
> >>> the series.
> >> One problem is remus. = =C2=A0My plan when dropping this patch was to drop all
> >> of = xc_domain_{save/restore}.c as well, but without remus migration-v2
> = >> support available, this will break existing set-ups.
> > = Hrm, how is that going wrt 4.5 freeze?
>
> I haven=E2=80=99t he= ard seen anything since v5 of this series (for which I did
> some qui= ck bugfixes and released v6).
>

FYI, thats not entirely t= rue. Yang did post a set of RFC patches for remus=C2=A0
support i= n migration v2, based on your V6 series (back in July)


It would actually = be helpful if you could cc me on the patches relevant to Remus,
or if t= here is anything specific to Remus that needs to be done. There are 100s of=
posts on Xen devel every day and its hard to keep track of every= thing posted to=C2=A0
Xen devel.


And I looking at your patch sets in



=

--001a11c2d9844a233d050303ec7e-- --===============7100697696313933220== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7100697696313933220==--