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

Re: dom0 PV looping on search_pre_exception_table()


  • To: Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Tue, 8 Dec 2020 18:13:46 +0000
  • Authentication-results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Delivery-date: Tue, 08 Dec 2020 18:14:03 +0000
  • Ironport-sdr: Byvv2QzLHlJxhCFcpxGzw5URdeBF5RrE7os7/Ao9YUw3cfEl4t+FeGVnn80G7eBefMtINbOfTI 17cmhQO6geRiTPa6I/hrSWW0SmrTTkUTggsY276R69CyLg7uDIXCn9uCEegwo7IvsCh/pCRGaJ JZSqKH89QLDQZOn5VT9AaRUfRIdo+inXFE+BxQMrpTc/lH6VfDTgJS1gOoEvQFJBvkLUODcYXO 5S7n7LyX2zDaRtZZkN0bcf+53bevav2mBTNwIkb6W2fUNtBKB5J9+qdun1w6GL0F0ppV+v+Yrk 6xI=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 08/12/2020 17:57, Manuel Bouyer wrote:
> Hello,
> for the first time I tried to boot a xen kernel from devel with
> a NetBSD PV dom0. The kernel boots, but when the first userland prcess
> is launched, it seems to enter a loop involving search_pre_exception_table()
> (I see an endless stream from the dprintk() at arch/x86/extable.c:202)
>
> With xen 4.13 I see it, but exactly once:
> (XEN) extable.c:202: Pre-exception: ffff82d08038c304 -> ffff82d08038c8c8
>
> with devel:
> (XEN) extable.c:202: Pre-exception: ffff82d040393309 -> ffff82d0403938c8      
>   
> (XEN) extable.c:202: Pre-exception: ffff82d040393309 -> ffff82d0403938c8      
>   
> (XEN) extable.c:202: Pre-exception: ffff82d040393309 -> ffff82d0403938c8      
>   
> (XEN) extable.c:202: Pre-exception: ffff82d040393309 -> ffff82d0403938c8      
>   
> (XEN) extable.c:202: Pre-exception: ffff82d040393309 -> ffff82d0403938c8      
>   
> [...]
>
> the dom0 kernel is the same.
>
> At first glance it looks like a fault in the guest is not handled at it 
> should,
> and the userland process keeps faulting on the same address.
>
> Any idea what to look at ?

That is a reoccurring fault on IRET back to guest context, and is
probably caused by some unwise-in-hindsight cleanup which doesn't
escalate the failure to the failsafe callback.

This ought to give something useful to debug with:

~Andrew

diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
index 70972f1085..62a7bcbe38 100644
--- a/xen/arch/x86/extable.c
+++ b/xen/arch/x86/extable.c
@@ -191,6 +191,10 @@ static int __init stub_selftest(void)
 __initcall(stub_selftest);
 #endif
 
+#include <xen/sched.h>
+#include <xen/softirq.h>
+const char *vec_name(unsigned int vec);
+
 unsigned long
 search_pre_exception_table(struct cpu_user_regs *regs)
 {
@@ -199,7 +203,13 @@ search_pre_exception_table(struct cpu_user_regs *regs)
         __start___pre_ex_table, __stop___pre_ex_table-1, addr);
     if ( fixup )
     {
-        dprintk(XENLOG_INFO, "Pre-exception: %p -> %p\n", _p(addr),
_p(fixup));
+        printk(XENLOG_ERR "IRET fault: %s[%04x]\n",
+               vec_name(regs->entry_vector), regs->error_code);
+
+        domain_crash(current->domain);
+        for ( ;; )
+            do_softirq();
+
         perfc_incr(exception_fixed);
     }
     return fixup;
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 0459cee9fb..1059f3ce66 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -687,7 +687,7 @@ const char *trapstr(unsigned int trapnr)
     return trapnr < ARRAY_SIZE(strings) ? strings[trapnr] : "???";
 }
 
-static const char *vec_name(unsigned int vec)
+const char *vec_name(unsigned int vec)
 {
     static const char names[][4] = {
 #define P(x) [X86_EXC_ ## x] = "#" #x




 


Rackspace

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