[PING] various patches

[PING] various patches

[Jan Beulich]

Following the rule for changes to THE REST code, is there any chance
I could get acks or otherwise on

http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg03475.html
http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg03478.html
http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg03878.html
http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg03880.html

Thanks, Jan

Re: [PING] various patches

[Ian Campbell]

On Mon, 2014-08-04 at 11:05 +0100, Jan Beulich wrote:
> Following the rule for changes to THE REST code, is there any chance
> I could get acks or otherwise on

Sorry, these sorts of things are very liable to fly under my radar, so
thanks for the explicit ping.

BTW $subjects would have been useful here. I've included them for the
benefit of the others on the CC. I'll reply mainly to the respective
threads rather than here.

> http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg03475.html

"fix qemu building with older make"

I think Ian J was happy with this in the end?

I don't mind the change FWIW.

> http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg03478.html

"lz4: check for underruns"

> http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg03878.html

        convert "no-" command line option prefix into "=no" for
        OPT_CUSTOM

but the thread itself is
        cmdline_parse: Convert no- prefix into =no for OPT_CUSTOM


> http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg03880.html
>

        xen/console: Better handing of console_timestamps as a boolean_param

Ian.

Re: [PING] various patches

[Jan Beulich]

>>> On 04.08.14 at 13:00, <Ian.Campbell@eu.citrix.com> wrote:

> On Mon, 2014-08-04 at 11:05 +0100, Jan Beulich wrote:
>> Following the rule for changes to THE REST code, is there any chance
>> I could get acks or otherwise on
> 
> Sorry, these sorts of things are very liable to fly under my radar, so
> thanks for the explicit ping.
> 
> BTW $subjects would have been useful here. I've included them for the
> benefit of the others on the CC. I'll reply mainly to the respective
> threads rather than here.
> 
>> http://lists.xenproject.org/archives/html/xen-devel/2014-07/msg03475.html 
> 
> "fix qemu building with older make"
> 
> I think Ian J was happy with this in the end?

Yes, but without formally giving an ack.

Jan

[PING] various patches

[Jan Beulich]

"REST"-maintainers,

is there any chance I could gets acks or otherwise on

http://lists.xenproject.org/archives/html/xen-devel/2014-09/msg01751.html
http://lists.xenproject.org/archives/html/xen-devel/2014-09/msg02105.html

Also, does anyone have comments on the approach taken in

http://lists.xenproject.org/archives/html/xen-devel/2014-09/msg02103.html

(see namely the not to be committed part of the description)?

Thanks, Jan

Re: [PING] various patches

[Ian Campbell]

On Wed, 2014-09-17 at 13:19 +0100, Jan Beulich wrote:
> "REST"-maintainers,
> 
> is there any chance I could gets acks or otherwise on
> 
> http://lists.xenproject.org/archives/html/xen-devel/2014-09/msg01751.html

This looks like x86 rather than rest? In any case it seems like Andrew
is looking into it, and if he is happy with it I think that should be
sufficient for you to go ahead.

> http://lists.xenproject.org/archives/html/xen-devel/2014-09/msg02105.html

I don't see anything wrong with this, but I'm not sure if the reasons
for Keir's original concerns have now gone away or the circumstances
have changed etc.

> Also, does anyone have comments on the approach taken in
> 
> http://lists.xenproject.org/archives/html/xen-devel/2014-09/msg02103.html
> 
> (see namely the not to be committed part of the description)?

The bit about migration to an older hypervisor not working? I think you
are right that we don't care to support that.

Ian.

Re: [PING] various patches

[Konrad Rzeszutek Wilk]

On Wed, Sep 17, 2014 at 06:06:40PM +0100, Ian Campbell wrote:
> On Wed, 2014-09-17 at 13:19 +0100, Jan Beulich wrote:
> > "REST"-maintainers,
> > 
> > is there any chance I could gets acks or otherwise on
> > 
> > http://lists.xenproject.org/archives/html/xen-devel/2014-09/msg01751.html
> 
> This looks like x86 rather than rest? In any case it seems like Andrew
> is looking into it, and if he is happy with it I think that should be
> sufficient for you to go ahead.

Except he is out for the next six days.
> 
> > http://lists.xenproject.org/archives/html/xen-devel/2014-09/msg02105.html
> 
> I don't see anything wrong with this, but I'm not sure if the reasons
> for Keir's original concerns have now gone away or the circumstances
> have changed etc.

Ditto, it looked OK to me but I needed to refresh on the possible
disadvantages of the r/w locks as compared to bytelocks.
> 
> > Also, does anyone have comments on the approach taken in
> > 
> > http://lists.xenproject.org/archives/html/xen-devel/2014-09/msg02103.html
> > 
> > (see namely the not to be committed part of the description)?
> 
> The bit about migration to an older hypervisor not working? I think you
> are right that we don't care to support that.
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: [PING] various patches

[Jan Beulich]

>>> On 17.09.14 at 19:06, <ian.campbell@citrix.com> wrote:
> On Wed, 2014-09-17 at 13:19 +0100, Jan Beulich wrote:
>> "REST"-maintainers,
>> 
>> is there any chance I could gets acks or otherwise on
>> 
>> http://lists.xenproject.org/archives/html/xen-devel/2014-09/msg01751.html 
> 
> This looks like x86 rather than rest? In any case it seems like Andrew
> is looking into it, and if he is happy with it I think that should be
> sufficient for you to go ahead.

Both help x86 only for now, but both change common (softirq) code
in order to do so.

>> http://lists.xenproject.org/archives/html/xen-devel/2014-09/msg02105.html 
> 
> I don't see anything wrong with this, but I'm not sure if the reasons
> for Keir's original concerns have now gone away or the circumstances
> have changed etc.

As said in the non-commit comment - I re-posted with the grown use
of rangesets in mind (namely the ones Paul added for the multiple
ioemu servers).

>> Also, does anyone have comments on the approach taken in
>> 
>> http://lists.xenproject.org/archives/html/xen-devel/2014-09/msg02103.html 
>> 
>> (see namely the not to be committed part of the description)?
> 
> The bit about migration to an older hypervisor not working? I think you
> are right that we don't care to support that.

Not just that, but also the arch_domain_unpause() approach.
Andrew was concerned about the possible impact, yet I can't
see a better approach to do post-restore adjustments with the
full new state guaranteed to be in place.

Jan

Re: [PING] various patches

[Ian Campbell]

On Thu, 2014-09-18 at 08:58 +0100, Jan Beulich wrote:
> >>> On 17.09.14 at 19:06, <ian.campbell@citrix.com> wrote:
> > On Wed, 2014-09-17 at 13:19 +0100, Jan Beulich wrote:
> >> "REST"-maintainers,
> >> 
> >> is there any chance I could gets acks or otherwise on
> >> 
> >> http://lists.xenproject.org/archives/html/xen-devel/2014-09/msg01751.html 
> > 
> > This looks like x86 rather than rest? In any case it seems like Andrew
> > is looking into it, and if he is happy with it I think that should be
> > sufficient for you to go ahead.
> 
> Both help x86 only for now, but both change common (softirq) code
> in order to do so.

So they do. In the meantime I see Tim has indicated he is happy with
them, and they look good to me to. I think I've understood correctly
that the arch side needs to opt in (IOW no changes needed for ARM until
we want to)

> >> http://lists.xenproject.org/archives/html/xen-devel/2014-09/msg02105.html 
> > 
> > I don't see anything wrong with this, but I'm not sure if the reasons
> > for Keir's original concerns have now gone away or the circumstances
> > have changed etc.
> 
> As said in the non-commit comment - I re-posted with the grown use
> of rangesets in mind (namely the ones Paul added for the multiple
> ioemu servers).

Namely those was what I didn't know about ;-)

> >> Also, does anyone have comments on the approach taken in
> >> 
> >> http://lists.xenproject.org/archives/html/xen-devel/2014-09/msg02103.html 
> >> 
> >> (see namely the not to be committed part of the description)?
> > 
> > The bit about migration to an older hypervisor not working? I think you
> > are right that we don't care to support that.
> 
> Not just that, but also the arch_domain_unpause() approach.
> Andrew was concerned about the possible impact, yet I can't
> see a better approach to do post-restore adjustments with the
> full new state guaranteed to be in place.

In the meantime Tim seems to be taking a look. I've obviously got no
objections to the nop function in the ARM case.

Ian.

Re: [PING] various patches

[Jan Beulich]

>>> On 22.09.14 at 11:37, <Ian.Campbell@eu.citrix.com> wrote:
> On Thu, 2014-09-18 at 08:58 +0100, Jan Beulich wrote:
>> >>> On 17.09.14 at 19:06, <ian.campbell@citrix.com> wrote:
>> > On Wed, 2014-09-17 at 13:19 +0100, Jan Beulich wrote:
>> >> "REST"-maintainers,
>> >> 
>> >> is there any chance I could gets acks or otherwise on
>> >> 
>> >> http://lists.xenproject.org/archives/html/xen-devel/2014-09/msg01751.html 
>> > 
>> > This looks like x86 rather than rest? In any case it seems like Andrew
>> > is looking into it, and if he is happy with it I think that should be
>> > sufficient for you to go ahead.
>> 
>> Both help x86 only for now, but both change common (softirq) code
>> in order to do so.
> 
> So they do. In the meantime I see Tim has indicated he is happy with
> them, and they look good to me to. I think I've understood correctly
> that the arch side needs to opt in (IOW no changes needed for ARM until
> we want to)

Right.

>> >> Also, does anyone have comments on the approach taken in
>> >> 
>> >> http://lists.xenproject.org/archives/html/xen-devel/2014-09/msg02103.html 
>> >> 
>> >> (see namely the not to be committed part of the description)?
>> > 
>> > The bit about migration to an older hypervisor not working? I think you
>> > are right that we don't care to support that.
>> 
>> Not just that, but also the arch_domain_unpause() approach.
>> Andrew was concerned about the possible impact, yet I can't
>> see a better approach to do post-restore adjustments with the
>> full new state guaranteed to be in place.
> 
> In the meantime Tim seems to be taking a look. I've obviously got no
> objections to the nop function in the ARM case.

Actually we seem to have found a way without modifying common
code.

Jan