Re: [Xen-devel] [xen-unstable-smoke test] 112957: regressions - trouble: broken/fail/pass

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Tue, 2017-09-05 at 15:06 -0700, Stefano Stabellini wrote:
> On Tue, 5 Sep 2017, Dario Faggioli wrote:
> > 
> > Re-checking things now, I actually do see that context_switch() on
> > ARM
> > is not 'terminal'. It call schedule_tail(), which on x86 does not
> > return, while in ARM, it does. I must have confused these two...
> > Sorry.
> > 
> > Also, mostly out of curiosity, still looking at ARM code, I'm not
> > getting at all how continue_new_vcpu() works (e.g., when/how is it
> > invoked?).
> 
> On ARM, context_switch() returns, unless it's the first time a new
> vcpu
> is run. In that case pc is set to continue_new_vcpu. __context_switch
> restores pc to continue_new_vcpu, returning to it.
>
Ah, yes, that's what I was missing! The fact that PC is assigned the
adress of continue_new_vcpu().. that's how it run. Only the first time,
as you're explaining.

Thanks! :-)

> From the second time onward a vcpu is run,
> context_switch returns normally.
> 
Right. And you (or someone else) can also confirm that the stack is
per-vCPU?

Or, in general, make sense out of the fact that the stack pointer
register changes in such a way that, when we get back in do_softirq(),
what's in the stack in the place where there was the 'cpu' local
variable has (at least in some circumstances) changed?

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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