From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: __dump_execstate() + x86's dump_exececution_state() Date: Fri, 12 Jan 2007 17:40:12 +0000 Message-ID: References: <45A7C2EA.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <45A7C2EA.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 12/1/07 16:18, "Jan Beulich" 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