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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 5 Sep 2017, Dario Faggioli wrote:
> So, I now think that what I did not understand, when looking at ARM
> code, was that context_switch() does indeed return, and hence we do at
> least another step inside the loop, and hit the ASSERT(), which I guess
> may trigger if what's in spite of the local variable 'cpu', in the new
> stack, is different than smp_processor_id().
> 
> 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.
> 
> Is this analysis correct?
>
> 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.  continue_new_vcpu
reset_stack_and_jumps to return_to_new_vcpu32/64.

__context_switch also saves the new registers, including pc, overwriting
the initial value of continue_new_vcpu with the return address within
context_switch. From the second time onward a vcpu is run,
context_switch returns normally.

(I think the above is correct, but I didn't double check by actually
running the code.)

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