__dump_execstate() + x86's dump_exececution_state()

__dump_execstate() + x86's dump_exececution_state()

[Jan Beulich]

I find it rather useless that due to the use of ud2 here, the context printed is
always in Xen, even if what was interrupted (and hence active at the point)
was guest code. I would want to utilize the frame smp_call_function_interrupt()
sees, and am therefore wondering if it would be acceptable to add a simple
hack to this function to pass the frame pointer as info in case the requested
info was NULL. Or whether there are other ideas how to enhance the situation
here.

Thanks, Jan

Re: __dump_execstate() + x86's dump_exececution_state()

[Keir Fraser]

On 12/1/07 16:18, "Jan Beulich" <jbeulich@novell.com> wrote:

> I find it rather useless that due to the use of ud2 here, the context printed
> is
> always in Xen, even if what was interrupted (and hence active at the point)
> was guest code. I would want to utilize the frame
> smp_call_function_interrupt()
> sees, and am therefore wondering if it would be acceptable to add a simple
> hack to this function to pass the frame pointer as info in case the requested
> info was NULL. Or whether there are other ideas how to enhance the situation
> here.

Good point. I've now fixed it to dump *both* guest context and Xen context
always (or print that the vcpu is idling and print only Xen context).

 -- Keir