WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] nested virtualization: tracing capabilities

To: Christoph Egger <Christoph.Egger@xxxxxxx>
Subject: Re: [Xen-devel] nested virtualization: tracing capabilities
From: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Date: Thu, 7 Apr 2011 15:49:13 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 07 Apr 2011 07:49:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D9DC97A.10209@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4D9DC97A.10209@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
At 15:26 +0100 on 07 Apr (1302189962), Christoph Egger wrote:
> # HG changeset patch
> # User cegger
> # Date 1302180533 -7200
> Tracing facility for nested virtualization
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@xxxxxxx>
> 
> diff -r ee39668a7840 -r aef9e2deb9a7 tools/xentrace/formats
> --- a/tools/xentrace/formats
> +++ b/tools/xentrace/formats
> @@ -5,6 +5,7 @@ 0x0001f002  CPU%(cpu)d  %(tsc)d (+%(relt
>  0x0001f003  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  cpu_change        0x%(1)08x
>  0x0001f004  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  trace_irq    [ vector = 
> %(1)d, count = %(2)d, tot_cycles = 0x%(3)08x, max_cycles = 0x%(4)08x ]
>  
> +0x00021002  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  continue_running    [ 
> dom:vcpu = 0x%(1)08x ]
>  0x00021011  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  running_to_runnable [ 
> dom:vcpu = 0x%(1)08x ]
>  0x00021021  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  running_to_blocked  [ 
> dom:vcpu = 0x%(1)08x ]
>  0x00021031  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  running_to_offline  [ 
> dom:vcpu = 0x%(1)08x ]
> @@ -34,7 +35,10 @@ 0x0002800d  CPU%(cpu)d  %(tsc)d (+%(relt
>  0x0002800e  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  switch_infprev    [ 
> old_domid = 0x%(1)08x, runtime = %(2)d ]
>  0x0002800f  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  switch_infnext    [ 
> new_domid = 0x%(1)08x, time = %(2)d, r_time = %(3)d ]
>  
> -0x00081001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  VMENTRY
> +0x00081401  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  nVMENTRY    [ rIP = 
> 0x%(1)08x ]
> +0x00081402  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  nVMEXIT     [ exitcode = 
> 0x%(1)08x, rIP  = 0x%(2)08x, intercepted = 0x%(5)01x ]
> +0x00081502  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  nVMEXIT     [ exitcode = 
> 0x%(1)08x, rIP  = 0x%(3)08x%(2)08x, intercepted = 0x%(6)01x ]
> +0x00081001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  VMENTRY     [ rIP = 
> 0x%(1)08x ]

Shouldn't these be kept in numerical order?

> diff -r ee39668a7840 -r aef9e2deb9a7 xen/arch/x86/hvm/emulate.c
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -45,6 +45,9 @@ static void hvmtrace_io_assist(int is_mm
>          size += 4;
>      }
>  
> +    *(uint32_t *)&buffer[size] = guest_cpu_user_regs()->eip;
> +    size += 4;
> +

...unconditionally overruning a stack buffer with a guest register. 

>      trace_var(event, 0/*!cycles*/, size, buffer);
>  }
>  
> @@ -153,8 +156,6 @@ static int hvmemul_do_io(
>      p->df = df;
>      p->data = value;
>  
> -    hvmtrace_io_assist(is_mmio, p);
> -
>      if ( is_mmio )
>      {
>          rc = hvm_mmio_intercept(p);
> @@ -166,6 +167,8 @@ static int hvmemul_do_io(
>          rc = hvm_portio_intercept(p);
>      }
>  
> +    hvmtrace_io_assist(is_mmio, p);
> +

Why so?

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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

<Prev in Thread] Current Thread [Next in Thread>