Re: [Xen-devel] [PING] various patches

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.09.14 at 11:37, <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> On Thu, 2014-09-18 at 08:58 +0100, Jan Beulich wrote:
>> >>> On 17.09.14 at 19:06, <ian.campbell@xxxxxxxxxx> 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


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