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

Re: [Xen-devel] __dump_execstate() + x86's dump_exececution_state()


  • To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Fri, 12 Jan 2007 17:40:12 +0000
  • Delivery-date: Fri, 12 Jan 2007 09:39:56 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acc2cLXw9MM7D6JjEdu5iwAX8io7RQ==
  • Thread-topic: [Xen-devel] __dump_execstate() + x86's dump_exececution_state()

On 12/1/07 16:18, "Jan Beulich" <jbeulich@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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