[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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?

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.