Xen devel - Jan 2007 - __dump_execstate() + x86''s dump_exececution_state()

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel