[PATCH] Allow debugging of SVM guests with gdbserver-xen

[PATCH] Allow debugging of SVM guests with gdbserver-xen

[Travis Betak]

Keir,

This patch provides (or at least provided) SVM similar functionality to
what VMX has by allowing source-level debugging of unmodified guests.

I did my development and testing against changeset 11131 and all worked
fine.  However, recent changesets have broken gdbserver-xen's memory
read/write interface with the guest --- at least with respect to SVM
guests.  I haven't examined the problem too closely yet, but I think
this is a side effect from the shadow2 merge.

Anyway, if acceptable, please apply to -unstable.  I'm going to look
at the libxc/ptrace code a little more closely to see if I can root
cause the problem.

   --travis


---


[HVM][SVM] Allow debugging of SVM guests with gdbserver-xen

Signed-off-by: Travis Betak <travis.betak@amd.com>

diff -r bfb710d768eb -r 113730d1bfc5 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Fri Aug 25 11:57:57 2006 -0500
+++ b/xen/arch/x86/hvm/svm/svm.c	Fri Aug 25 11:58:10 2006 -0500
@@ -2705,19 +2705,48 @@ asmlinkage void svm_vmexit_handler(struc

      switch (exit_reason)
      {
+
+#ifdef XEN_DEBUGGER
+
      case VMEXIT_EXCEPTION_DB:
-    {
-#ifdef XEN_DEBUGGER
          svm_debug_save_cpu_user_regs(&regs);
          pdb_handle_exception(1, &regs, 1);
          svm_debug_restore_cpu_user_regs(&regs);
-#else
-        svm_store_cpu_user_regs(&regs, v);
-        domain_pause_for_debugger(); 
-#endif
-    }
-    break;
-
+        break;
+
+    case VMEXIT_EXCEPTION_BP:
+        svm_debug_save_cpu_user_regs(&regs);
+        pdb_handle_exception(3, &regs, 1);
+        svm_debug_restore_cpu_user_regs(&regs);
+        break;
+
+#else /* XEN_DEBUGGER */
+
+    case VMEXIT_EXCEPTION_DB:
+
+        if (test_bit(_DOMF_debugging, &v->domain->domain_flags))
+        {
+            svm_store_cpu_user_regs(&regs, v);
+            domain_pause_for_debugger();
+        }
+        else
+        {
+            svm_inject_exception(v, TRAP_debug, 0, 0);
+        }
+
+        break;
+
+    case VMEXIT_EXCEPTION_BP:
+ 
+        if (test_bit(_DOMF_debugging, &v->domain->domain_flags))
+            domain_pause_for_debugger();
+        else 
+            svm_inject_exception(v, TRAP_int3, 0, 0);
+
+        break;
+
+#endif /* ! XEN_DEBUGGER */
+
      case VMEXIT_NMI:
          do_nmi(&regs, 0);
          break;
@@ -2735,19 +2764,6 @@ asmlinkage void svm_vmexit_handler(struc
          /*
           * Nothing to do, in fact we should never get to this point.
           */
-        break;
-
-    case VMEXIT_EXCEPTION_BP:
-#ifdef XEN_DEBUGGER
-        svm_debug_save_cpu_user_regs(&regs);
-        pdb_handle_exception(3, &regs, 1);
-        svm_debug_restore_cpu_user_regs(&regs);
-#else
-        if ( test_bit(_DOMF_debugging, &v->domain->domain_flags) )
-            domain_pause_for_debugger();
-        else 
-            svm_inject_exception(v, TRAP_int3, 0, 0);
-#endif
          break;

      case VMEXIT_EXCEPTION_NM:

Re: [PATCH] Allow debugging of SVM guests with gdbserver-xen

[Keir Fraser]

On 25/8/06 9:26 pm, "Travis Betak" <travis.betak@amd.com> wrote:

> This patch provides (or at least provided) SVM similar functionality to
> what VMX has by allowing source-level debugging of unmodified guests.
> 
> I did my development and testing against changeset 11131 and all worked
> fine.  However, recent changesets have broken gdbserver-xen's memory
> read/write interface with the guest --- at least with respect to SVM
> guests.  I haven't examined the problem too closely yet, but I think
> this is a side effect from the shadow2 merge.
> 
> Anyway, if acceptable, please apply to -unstable.  I'm going to look
> at the libxc/ptrace code a little more closely to see if I can root
> cause the problem.

The patch doesn't apply to unstable tip, so let's leave this until you've
resolved the issues and post a fully working patch.

 -- Keir

Re: [PATCH] Allow debugging of SVM guests with gdbserver-xen

[Travis Betak]

On Mon, 28 Aug 2006, Keir Fraser wrote:

> On 25/8/06 9:26 pm, "Travis Betak" <travis.betak@amd.com> wrote:
>
>> This patch provides (or at least provided) SVM similar functionality to
>> what VMX has by allowing source-level debugging of unmodified guests.
>>
>> I did my development and testing against changeset 11131 and all worked
>> fine.  However, recent changesets have broken gdbserver-xen's memory
>> read/write interface with the guest --- at least with respect to SVM
>> guests.  I haven't examined the problem too closely yet, but I think
>> this is a side effect from the shadow2 merge.
>>
>> Anyway, if acceptable, please apply to -unstable.  I'm going to look
>> at the libxc/ptrace code a little more closely to see if I can root
>> cause the problem.
>
> The patch doesn't apply to unstable tip, so let's leave this until you've
> resolved the issues and post a fully working patch.

OK.  I'll try a working updated patch out.

BTW, Have you heard any reports that this feature has stopped working on
the VT side?

   --travis

Re: [PATCH] Allow debugging of SVM guests with gdbserver-xen

[Keir Fraser]

On 28/8/06 12:06 pm, "Travis Betak" <travis.betak@amd.com> wrote:

>>> Anyway, if acceptable, please apply to -unstable.  I'm going to look
>>> at the libxc/ptrace code a little more closely to see if I can root
>>> cause the problem.
>> 
>> The patch doesn't apply to unstable tip, so let's leave this until you've
>> resolved the issues and post a fully working patch.
> 
> OK.  I'll try a working updated patch out.
> 
> BTW, Have you heard any reports that this feature has stopped working on
> the VT side?

No. There's nothing VT or AMDV specific in the userspace code so I'd be
surprised if it worked on one and not the other.

 -- Keir

Re: Re: [PATCH] Allow debugging of SVM guests with gdbserver-xen

[Gerd Hoffmann]

Keir Fraser wrote:
> 
>> BTW, Have you heard any reports that this feature has stopped working on
>> the VT side?

/me raises it's hand, unstable:11731, x86_32, VT box.

Another gdbserver-xen + hvm question:  How can I debug hvm bootup?  "xm
create -p ...", attach gdbserver-xen, then try to step forward using
"nexti" in gdb doesn't work.  Seems to start with eip = 0, wheras I'd
expect it start at 0x1000000 (hvmloader entry point).

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg