From mboxrd@z Thu Jan  1 00:00:00 1970
From: Don Slutz <dslutz@verizon.com>
Subject: Re: [PATCH v5 15/17] xenctx: Fix handling of
	!guest_protected_mode
Date: Mon, 24 Mar 2014 18:35:22 -0400
Message-ID: <5330B32A.4030205@terremark.com>
References: <1395342425-16260-1-git-send-email-dslutz@verizon.com>	
	<1395342425-16260-16-git-send-email-dslutz@verizon.com>
	<1395414598.19839.135.camel@kazak.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1395414598.19839.135.camel@kazak.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Campbell <Ian.Campbell@citrix.com>, Don Slutz <dslutz@verizon.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

On 03/21/14 11:09, Ian Campbell wrote:
> On Thu, 2014-03-20 at 15:07 -0400, Don Slutz wrote:
>> @@ -851,6 +861,9 @@ static int print_stack(vcpu_guest_context_any_t *ctx, int vcpu, int width, guest
>>               return -1;
>>       }
>>   
>> +    if ( !guest_protected_mode )
>> +        return 0;
>> +
>>       if(xenctx.stack_trace)
>>           printf("Stack Trace:\n");
>>       else
>> @@ -1016,7 +1029,8 @@ static void dump_ctx(int vcpu)
>>   #ifndef NO_TRANSLATION
>>       if (print_code(&ctx, vcpu))
>>           return;
>> -    if ( kernel_addr(instr_pointer(&ctx)) >= KERNEL_TEXT_ADDR )
>> +    if ( !guest_protected_mode ||
> Aren't this and the check in the previous hunk contradictory and/or
> equivalent (I can't decide which)

Nope. The check in the previous hung is to say that in !guest_protected_mode
(aka real mode or 16bit mode), skip Call or Stack trace.

This check is to say do the stack dump.


Here is the output you get:
xenctx -t 5
cs:eip: f000:0000f033
flags: 00000046 z p
ss:esp: e000:0000f85a
eax: 00000000   ebx: 00000000   ecx: 00006b62   edx: 00000000
esi: 0000e000   edi: 0000f8b8   ebp: 00000000
  ds:     e000    es:     0040    fs:     0000    gs:     0000
Code (instr addr 000ff033)
fc 8e d5 67 8b 67 f8 8e dd 66 ff d1 8e de 8e d6 66 8b 26 b0 f0 <66> 89 3e b0 f0 66 5e 66 5b 66 5e


Stack:
000ef85a: 00000000 0000f88a 00000000 00000001 00000000 00006bbd 00000040 00000040
000ef87a: 00000000 0000000e 00001ff0 0000d4cb 00000000 0000000e 00000000 00001ff0
000ef89a: 00000040 ffffffff 00008e26 00001100 00008e30 1fee0246 00000000 1f000000
000ef8ba: 00000084 bb660000 0003fefc 3c038a67 66087464 03fef8bb 6606eb00 03ff00bb
000ef8da: 00b86600 67000a00 b0038966 00b3ba00 baaa0fee 3cec00b2 ba0a75f0 83edb004


Since this is 16 bit mode, maybe the stack should be:


Stack:
ef85a: 0000 0000 f88a 0000 0000 0000 0001 0000 0000 0000 6bbd 0000 0040 0000 0040 0000
ef87a: 0000 0000 000e 0000 1ff0 0000 d4cb 0000 0000 0000 000e 0000 0000 0000 1ff0 0000
ef89a: 0040 0000 ffff ffff 8e26 0000 1100 0000 8e30 0000 0246 1fee 0000 0000 0000 1f00
ef8ba: 0084 0000 0000 bb66 fefc 0003 8a67 3c03 7464 6608 f8bb 03fe eb00 6606 00bb 03ff
ef8da: 6600 00b8 0a00 6700 8966 b003 ba00 00b3 0fee baaa 00b2 3cec 75f0 ba0a b004 83ed


    -Don Slutz



>> +         kernel_addr(instr_pointer(&ctx)) >= KERNEL_TEXT_ADDR )
>>           if ( print_stack(&ctx, vcpu, guest_word_size,
>>                            stack_pointer(&ctx)) )
>>               return;
>