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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 6 Sep 2017, Dario Faggioli wrote:
> 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?

Yes, we have a per-vCPU stack on ARM.


> 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?

I think yes, it could cause the smp_processor_id() mismatch.

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